On 02/09/18 11:48, Stuart Henderson wrote:
> 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.

cryptography 1.9 (2017-05-29) adds support for LibreSSL 2.5.x.  The
package in question requires <=1.8.2 due to API changes in 1.9.

You are correct that current versions of py-cryptography work correctly
with LibreSSL, and I was quoted out of context.  I specifically noted in
a different email that the problem was *older* versions of cryptography.
 It'd be much better if Taiga and Mailman3 would just upgrade their
requirements, but that would break systems where pyca isn't at the 2.x
API level yet, so they are hesitant to do so.

>> 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.

I was more asking if headers for libtls could be installed at the same
time as actual OpenSSL headers.  This would allow me to build and test
different backends (i.e., software that can use either OpenSSL 1.1 or
libtls from LibreSSL) without needing to switch to chroot.  But I see
now why this would be impossible, so thank you for clearing that up.

All the best,

A. Wilcox (awilfox)
Project Lead, Adélie Linux

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to