On Mon, Apr 15, 2024 at 09:47:02PM +0200, Alex Holst wrote:
> In troubleshooting a recurring problem of 'pip install cryptography' failing to build on OpenBSD, I took the long and winded road to end up at this GitHub issue:
> 
> https://github.com/pyca/cryptography/issues/10817
> 
> It can be summarized as "rust-openssl pins the known versions of LibreSSL that are verified to work as LibreSSL does not offer API or ABI stability between major versions".
> 
> So 3.9.0 fails to build because it's not 3.8.1, and so on.

Yes. It's a long story, but the short version is that it's a design
choice of rust ffi that it is safer to copy and hardcode things because
the preprocessor is terribly unsafe. rust-openssl made the dubious
choice of doing this by hand, which means that this can get out of sync,
so they need to do strict version checks to make sure the values didn't
change.

I try to feed them changes upstream and also make an effort to avoid
what they consider ABI breaks (which is distinct from our notion of ABI
breaks), but your best bet is to use the latest stable version of
libressl and stable and the latest released versions of rust-openssl to
avoid having to patch things with cargo.

current should usually build with HEAD of rust-openssl if you bypass the
version checks, but then you need to follow what we're doing closely.

> The LibreSSL release page has made no claims about stability since 2016: "subsequent 2.4.x releases have a stable API and ABI".

I hate libressl's versioning scheme, but it is what it is (it has more
numbers than necessary and it is super confusing). Basically 3.x.y is
unstable until y is declared stable, and from that point on 3.x.z is
stable for all z >= y. And then there is the additional issue that the
version in OpenBSD might be different from 3.x.y as well for release
cycle reasons.

Nowadays people assume that three numbers imply semantic versioning
which emphatically isn't the case here.