| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 30/09/15 03:29 PM, Anthony G. Basile wrote: |
| 5 |
> On 9/30/15 12:18 PM, Ian Stakenvicius wrote: On 30/09/15 07:42 |
| 6 |
> AM, hasufell wrote: |
| 7 |
>>>> * libressl has to conflict with openssl |
| 8 |
> Right now libressl exports many of the same symbols as openssl |
| 9 |
> right? What if it didn't -- that is, we forced a symver map with |
| 10 |
> a libressl prefix on all symbols? That would ensure anything |
| 11 |
> built against libressl would not b0rk if openssl was loaded, or |
| 12 |
> more specifically, if something else was loaded that was built |
| 13 |
> against and links to openssl. |
| 14 |
> |
| 15 |
>> Yes you could use symbol versioning, and you can do the side by |
| 16 |
>> side by renaming the library but that's a real pita for us |
| 17 |
>> since we'd have to hack build systems to link against the |
| 18 |
>> correct library name. Ths should have been done upstream. |
| 19 |
|
| 20 |
Library doesn't have to be renamed as long as it's in a different |
| 21 |
path, does it? If openssl/libssl.so is loaded and none of the |
| 22 |
symbols exist due to the symbols expected being 'libressl_*', then |
| 23 |
libressl/libssl.so being loaded will provide the necessary symbols |
| 24 |
and not conflict, right? Or am i missing something subtle here, |
| 25 |
like that libressl/libssl.so will never be loaded because the |
| 26 |
libssl.so from openssl/ was loaded? |
| 27 |
|
| 28 |
Note in the above i'm specifically not addressing side-by-side lib |
| 29 |
installation here and getting rdeps to build against the right ones |
| 30 |
- -- just how rdeps use libssl.so if two different ones were installed. |
| 31 |
|
| 32 |
On dealing with side-by-side installation in rdeps, technically |
| 33 |
don't we just start filing en masse "use pkg-config" patches to |
| 34 |
upstreams? we could just start doing that now couldn't we? It's |
| 35 |
2015, shouldn't everything be using pkg-config or similar to find |
| 36 |
libs by now? |
| 37 |
|
| 38 |
|
| 39 |
> |
| 40 |
>> @rich0. Just a side comment. You said somewhere that maybe |
| 41 |
>> apache will choose openssl and postfix libressl and then we'll |
| 42 |
>> be in trouble. No. The incompatibility is at the abi not api |
| 43 |
>> level. So, for example, some struct size might be different |
| 44 |
>> between the two because of internal implementation details, but |
| 45 |
>> both should provide a definition of the same struct in their |
| 46 |
>> header with the same members. ie. apache should compile against |
| 47 |
>> either openssl or libressl and work, you just can't swap out |
| 48 |
>> your libssl without recompiling apache which you could do if |
| 49 |
>> you had full api compat. |
| 50 |
|
| 51 |
|
| 52 |
What happens in the case of a proprietary binary package that links |
| 53 |
to libssl? Even if we bundle the libssl.so variant that it needs, |
| 54 |
don't we run the risk of the package using the wrong one (esp. in |
| 55 |
the case where that package is i.e. dlopen'ed by something else?) |
| 56 |
|
| 57 |
-----BEGIN PGP SIGNATURE----- |
| 58 |
Version: GnuPG v2 |
| 59 |
|
| 60 |
iF4EAREIAAYFAlYNP7YACgkQAJxUfCtlWe3bFAEAtNa6rrLohwL0iQ/I64BaPhnw |
| 61 |
HBZiG/I2kwRWOVujDz4A/iivzF8wsG8f84mTLyn9VebGoKHFNgf52bw6erXFD/rT |
| 62 |
=jD6F |
| 63 |
-----END PGP SIGNATURE----- |
Archives