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 : bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
