Re: [gentoo-dev] LibreSSL import plan

[Rich Freeman]

On Wed, Sep 30, 2015 at 3:29 PM, Anthony G. Basile <blueness@g.o> wrote:
>
> Yes you could use symbol versioning, and you can do the side by side by
> renaming the library but that's a real pita for us since we'd have to hack
> build systems to link against the correct library name.  Ths should have
> been done upstream.
>

Agree, though to be fair it was a failing in openssl before it was a
failing in libressl:
readelf -sW /usr/lib64/libssl.so | grep "@"
(output: nothing that didn't come from glibc)

> You'd have to name the libraries differently and you'd have to hack the
> LDLFAGS to aim the build to the correct library.  That, in my opinion, is
> the killer to this idea.  There is also the issue that some libc's like
> uclibc don't do symbol versioning, but I would deal with that in other ways.

++  There might be some solutions to automate this, but it would be a
PITA.  I think the better solution is to fix C itself.

>
> @rich0.  Just a side comment.  You said somewhere that maybe apache will
> choose openssl and postfix libressl and then we'll be in trouble.  No.  The
> incompatibility is at the abi not api level.  So, for example, some struct
> size might be different between the two because of internal implementation
> details, but both should provide a definition of the same struct in their
> header with the same members.  ie. apache should compile against either
> openssl or libressl and work, you just can't swap out your libssl without
> recompiling apache which you could do if you had full api compat.

I agree with this as long as both projects maintain API compatibility.
Whether that happens remains to be seen.  If openssl adds a new
feature and libressl decides that is a "bad feature" or libressl adds
a new feature and openssl doesn't have the manpower to keep up, or
whatever, then we'll start seeing things break, and then everybody
gets to pick sides.

As may be happening with ffmpeg/libav I suspect that eventually one
side or the other will become dominant, and at that point users will
have a clean solution again.  In the meantime they get to see WW3
unfurl on their desktops as they are forced to pick a side and decide
which packages they want to install.  I guess that would be a good
time to plug containers again.  (You know that symbol versioning is
broken when the solution is basically to install a completely
independent userspace for every process you run.)

-- 
Rich