Re: [gentoo-dev] LibreSSL import plan

[Anthony G. Basile]

On 9/30/15 12:18 PM, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 30/09/15 07:42 AM, hasufell wrote:
>> * libressl has to conflict with openssl
> Right now libressl exports many of the same symbols as openssl
> right?  What if it didn't -- that is, we forced a symver map with a
> libressl prefix on all symbols?  That would ensure anything built
> against libressl would not b0rk if openssl was loaded, or more
> specifically, if something else was loaded that was built against
> and links to openssl.

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.

An example of how this could be done is xattrs which is provided both by 
your libc and by libattr.  Most of your systems already have this so 
here's a little toy program:

#include <stdio.h>
#include <sys/types.h>
#include <sys/xattr.h>

int main() {
     char x[] = "/tmp/test.XXXXXX";
     int fd = mkostemp(x);
     fsetxattr(fd, "user.test", "test", 4, 0);
     close(fd);
     unlink(x);
}

which you can compile and read the symbols as follows:

1. linking against libc:

# gcc -o test test.c

# readelf -sW test | grep fsetxattr
      2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND 
fsetxattr@GLIBC_2.3 (3)
    36: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND 
fsetxattr@@GLIBC_2.3

# readelf -sW /lib/libc.so.6 | grep fsetxattr
   1929: 00000000000f50f0    36 FUNC    GLOBAL DEFAULT   11 
fsetxattr@@GLIBC_2.3


2. linking against libattr:

# gcc -o test test.c -lattr

# readelf -sW test | grep fsetxattr
      3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND 
fsetxattr@ATTR_1.0 (3)
    36: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND 
fsetxattr@@ATTR_1.0

# readelf -sW /lib/libattr.so.1 | grep fsetxattr
     44: 0000000000003c40    85 FUNC    GLOBAL DEFAULT   11 
fsetxattr@@ATTR_1.0

>
> This wouldn't need any rdep patching at all, and would ensure symbol
> collisions between the two projects would not occur.  It doesn't
> explicitly enable side-by-side installation but it would help ensure
> things built for one project wouldn't use symbols from the other's
> lib expecting compatibility and randomly fail.
>
> ...or am I mis-understanding the major issue with the
> libressl/openssl conflict?

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.

For what its worth, hasufell's idea is the best we have.  The virtual 
won't work because of the danger of switching between openssl and 
libressl because we haven't cleaned up the whole || ( dep dep ) logic.  
You want a system with either one or the other, so have them block and 
choose between them with a USE flag.

@hasufell.  Sorry I didn't help more with this project, but real life is 
kicking my butt these days.  But total support from my end and thanks.  
The OpenBSD peeps have an excellent reputation and while I can't claim 
to have looked at their code in detail and convinced myself directly, I 
trust them based on their track record.   I plan to make use of libressl 
for enhanching security on the releng stuff I push out.  That wiki page 
comparing security flaws doesn't surprise me.  Time will tell who will 
have the best record in the long run.

@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.

>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iF4EAREIAAYFAlYMC3EACgkQAJxUfCtlWe34nwD+N+4s1ZFVLS8CGokYOEa64U6o
> EINP0tsAe2EyA/cpy6oBANoIyxf7bfPStLPofV1ZW7/7+z3DsmtSqYztsU6dptmz
> =oAIp
> -----END PGP SIGNATURE-----
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA