On 2018-02-09, Kevin Chadwick <m8il1i...@gmail.com> wrote: > It isn't just this. Qt 5.10 introduces new dependency on OpenSSL 1.1 > APIs for improved security, and LibreSSL does not implement those APIs > at all.
btw I haven't looked at Qt but some ports are already held back in OpenBSD because it's just getting too painful to manage the changes they've made to support openssl 1.1 api... > Also, as mentioned in my other email, one pain point is something like > mailman or taiga, which require Python Cryptography package version 1.7. > This version requires OpenSSL APIs that LibreSSL removed. I don't understand that, Cryptography is OK with LibreSSL. There have been some problems at various times but they were either patched locally or fixed upstream - we're a couple of point releases behind the latest at the moment with no libressl-related patches - and I'd very surprised if latest upstream had problems at the moment. The problem in your other email is internal SSL functions in Python (maintained by a redhat dev in Python core), not Cryptography (https://cryptography.io/, maintained separately). > One question I do have is: is there a way to disable the OpenSSL > compatibility in LibreSSL? It would be good for packages that require > LibreSSL (libressl-dev) to be buildable even if openssl-dev is installed > (preventing something like the above Python situation). No, there wouldn't be anything left without the OpenSSL-compatible-ish code. The big problem is if you have programs/libraries using OpenSSL they can't be linked with programs/libraries using LibreSSL. (Likewise, things using OpenSSL 1.0 can't be linked with things using 1.1). Many of the symbol names are the same so would conflict.