| 1 |
On 6 April 2015 at 23:06, Paul B. Henson <henson@×××.org> wrote: |
| 2 |
> What are the downsides of the approach pkgsrc is tentatively taking, |
| 3 |
where there are no modifications to libressl but the libraries are |
| 4 |
installed in an alternative location? Packages that require libressl can |
| 5 |
just use the appropriate linker options to find those libraries rather than |
| 6 |
the openssl ones? |
| 7 |
|
| 8 |
https://blog.flameeyes.eu/2014/07/libressl-drop-in-and-abi-leakage |
| 9 |
|
| 10 |
Let's say you have program foo that uses libtls and libssl functions *and* |
| 11 |
CURL. |
| 12 |
|
| 13 |
Now you built CURL against openssl, but foo requires libtls, so you link it |
| 14 |
against libressl. What happens when you run foo? |
| 15 |
|
| 16 |
Symbols from openssl's libssl and libressl's libssl have the same name for |
| 17 |
API compatibility, right? So whichever of the two is loaded first (I |
| 18 |
*think* that's libressl but it is of course loader-dependent and in the |
| 19 |
case of glibc it depends on the environment variables too) will provide the |
| 20 |
symbols. But their ABIs are different so the calls coming from CURL (built |
| 21 |
against OpenSSL) will provide different data structures and parameter size |
| 22 |
than expected by libressl, or vice-versa. |
| 23 |
|
| 24 |
Given these are security functions, the collisions are even riskier than |
| 25 |
just crashing, especially as *most* of the functions will likely work |
| 26 |
either way, as long as the same set of allocators/users/deallocators are |
| 27 |
used… |
| 28 |
|
| 29 |
Diego Elio Pettenò — Flameeyes |
| 30 |
https://blog.flameeyes.eu/ |
Archives