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.

Reply via email to