On 2018-02-09, A. Wilcox <awil...@adelielinux.org> wrote:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> From: "A. Wilcox" <awil...@adelielinux.org>
> To: email@example.com
> Message-ID: <b265c12d-d9b3-f0c0-73df-8f0ec7e83...@adelielinux.org>
> Subject: Re: LibreSSL Linux portability and OpenBSD security
> References: <slrnp7rnrq.205u....@naiad.spacehopper.org>
> In-Reply-To: <slrnp7rnrq.205u....@naiad.spacehopper.org>
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 8bit
> 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.
Ah thanks, yes the older one needed a patch, that one was relatively simple
as far as libressl patches go, we had this:
(though we don't have Mailman3 or Taiga in ports, so I don't know if those
in particular will work with it).
More recently I've been banging my head against things with a mixture
of OPENSSL_VERSION_NUMBER 0x101000... ifdefs, some of which need changing
to exclude LibreSSL, but others of which need keeping. These have been
getting more complicated than previously (and obviously going to see
more of this as other programs switch to supporting OpenSSL 1.1 API).
>>> 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
>> 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.
For simpler things it would be quite nice to have either a version of
libtls that's been ported to OpenSSL 1.1, or a version with the
libssl/libcrypto symbols renamed.
Though looking at the programs which _actually_ use libtls at present,
they aren't going to be pulling in other libraries that might use
OpenSSL, so just installing to paths which aren't usually searched might