Live data from Hacker News

OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f

openssl.org

31–40 of 47 posts

Re: OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f

#31
post #23

Earlier quoted context omitted.

Is there a reason why something as important as openssl is not being backported to keep up with the most recent versions?

Compatibility with other libraries and testing effort. You end up back porting everything. Ubuntu backports the fixes them instead (i.e. Ubuntu's 1.0.2 will be patch with CVE fixes going forward instead of backporting 1.1 wholesale).

Also stability of APIs/ABIs: within a major Ubuntu/Debian version, there is an implicit contract in most cases that if you build something against a library/software provided by the distribution, it will not break after an upgrade of said library/software.

To enforce that, a policy of version freeze+backport of bug/security fixes is almost always necessary as very few upstream projects will maintain separate branches and have a clear policy about API/ABI breakages.

(OpenSSL is actually somewhat of an exception in that regard).

Re: OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f

#33
post #31

Earlier quoted context omitted.

Compatibility with other libraries and testing effort. You end up back porting everything. Ubuntu backports the fixes them instead (i.e. Ubuntu's 1.0.2 will be patch with CVE fixes going forward instead of backporting 1.1 wholesale).

Also stability of APIs/ABIs: within a major Ubuntu/Debian version, there is an implicit contract in most cases that if you build something against a library/software provided by the distribution, it will not break after an upgrade of said library/software. To enforce that, a policy of version freeze+backport of bug/security fixes is almost always necessary as very few upstream projects will maintain separate branches…

OpenSSL actually did a breaking API change as recent as 1.1.1e (reverted in 1.1.1f to be fair):

https://bugs.python.org/issue40018

And broke the ABI in 1.0.2g:

https://bugzilla.redhat.com/show_bug.cgi?id=1313509

I don't mean to bash on OpenSSL here and agree they generally do an exceptional job at keeping the public interface stable. Just offering some context. These things are difficult.

Re: OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f

#34
post #27
post #5

Earlier quoted context omitted.

I have no idea what a full list looks like.. but the nginx:1.17.10-alpine docker image contains the following: / # nginx -V nginx version: nginx/1.17.10 built by gcc 9.2.0 (Alpine 9.2.0) built with OpenSSL 1.1.1d 10 Sep 2019

Mine has a "running with..." part after that. built with OpenSSL 1.1.1d 10 Sep 2019 (running with OpenSSL 1.1.1g 21 Apr 2020)

If it doesn't print the "running with" line, it's running with the same version it was built with:

https://hg.nginx.org/nginx/file/stable-1.18/src/core/nginx.c...

Re: OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f

#36
post #30
post #15

Sure, let's continue to reward incompetence by further funding openssl. In a sane world, everybody would have switched to libressl ages ago.

The few who switched to LibreSSL actually switched back to OpenSSL (Alpine, HardenedBSD). Void is considering switching back too: https://github.com/void-linux/void-packages/issues/20935

Their logic is a bit weird to me, I would definitely choose a fork from professional that re-write everything with a security perspective, over a bad library trying to be hardened .

Re: OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f

#37
post #30

Earlier quoted context omitted.

The few who switched to LibreSSL actually switched back to OpenSSL (Alpine, HardenedBSD). Void is considering switching back too: https://github.com/void-linux/void-packages/issues/20935

Their logic is a bit weird to me, I would definitely choose a fork from professional that re-write everything with a security perspective, over a bad library trying to be hardened .

The Void conundrum is that most software does not support LibreSSL's APIs, and that is especially rough because Void is rolling release. OpenBSD does not write patches for the latest Qt release, so people with little crypto experience have to write those patches.

Re: OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f

#38

Earlier quoted context omitted.

Their logic is a bit weird to me, I would definitely choose a fork from professional that re-write everything with a security perspective, over a bad library trying to be hardened .

The Void conundrum is that most software does not support LibreSSL's APIs, and that is especially rough because Void is rolling release. OpenBSD does not write patches for the latest Qt release, so people with little crypto experience have to write those patches.

Which is a bizarre statement, all ports development happens on the OpenBSD -current branch, which is effectively a rolling release for developers/users running snapshots.

All of those projects that switched were simply expecting LibreSSL/OpenBSD to upstream support, when it hasn't got nearly the same numbers of developers.

Also, there were other problems with updating Qt on OpenBSD, but that was resolved. It is maintained by a single developer.

https://marc.info/?l=openbsd-ports-cvs&m=158411843726544&w=2

Re: OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f

#39
post #32

Is BoringSSL affected?

or LibreSSL?

No. LibreSSL fork predates the issue, and has its own TLS 1.3 implementation. I'd expect the situation to be similar with Google's BoringSSL, but I don't how closely they track OpenSSL, if at all.

Re: OpenSSL high-severity bug – affects 1.1.1d, 1.1.1e, 1.1.1f

#40
post #33
post #31

Earlier quoted context omitted.

Also stability of APIs/ABIs: within a major Ubuntu/Debian version, there is an implicit contract in most cases that if you build something against a library/software provided by the distribution, it will not break after an upgrade of said library/software. To enforce that, a policy of version freeze+backport of bug/security fixes is almost always necessary as very few upstream projects will maintain separate branches…

OpenSSL actually did a breaking API change as recent as 1.1.1e (reverted in 1.1.1f to be fair): https://bugs.python.org/issue40018 And broke the ABI in 1.0.2g: https://bugzilla.redhat.com/show_bug.cgi?id=1313509 I don't mean to bash on OpenSSL here and agree they generally do an exceptional job at keeping the public interface stable. Just offering some context. These things are difficult.

To be fair "these things are difficult" if your ABI is terribly designed.

If you've used modern libpng you can thank people like me for the fact you don't need to recompile or even sometimes rewrite code after every micro version release.

Example of something libpng did before we "gently" explained that it's stupid: re-order the public data structures in a "bug fix" release. Because the old order looked untidy see, and so long as every program is recompiled with the new version of the library it won't break...

Post reply on HN