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