Much though I respect the authors of openssl back to ssleay (I worked at UQ where Tim and Eric worked) i think this is a retrograde move, and it would have been better to make libressl capable, but, its easy to say these things, far easier than it is to make them true.
I think sometimes, sw dependencies like openssl are too dangerous. We should have people using Peter Gutmans crypto library, or Dan Bernstein. Glomming it all into openssl was not good.
I do stuff in rfc3779 which got baked into openssl and not having it in other libraries is a pain. We partly funded the baking, so I guess we own the consequence.
Yes. at one point, it was the only code I could find which would reissue a certificate, using only the certificate itself as a CSR rather than making the private key holder reissue a request.
At this point, it's probably the right call. OpenSSL 2021 is nothing like OpenSSL 2014 (jesus i'm old), and is probably a better bet at this point than LibreSSL just by dint of the amount of energy that's allocated to it.
(Only speaking for Windows because I don't know anything about OSX.)
>Do Windows and MacOS have their own libraries separate from OpenSSL?
Yes, CAPI/CNG (general crypto) + SChannel (TLS).
>Do applications statically link OpenSSL?
If they want to. Linux-first programs often have a hard dependency on openssl rather than use pluggable crypto, so they include openssl in their installation package. Openssl can be compiled just fine for Windows after all.
Perhaps someone can shed light on this for me, a couple years ago I had an issue where libcurl with libressl stopped working in the new year with connections to a bunch of web servers, but switching to libcurl with openssl fixed my issue, though I never found out why.
IMHO, LibreSSL was doomed to "fail" by the mere fact that it was not picked up by Linux distributions to replace OpenSSL, the same way that x.org had replaced XFree86. Linux's influence's simply too big. LibreSSL will survive in the BSDs, and OpenSSH. That is, until OpenSSH's forked for whatever reason and the fork becomes the standard ssh on Linux distributions. I fear that's inevitable (cf. zfs).
FWIW, I've been in the game a long time. I understand what rolling release means. In this case it means, sorry if you bought anything in the last 2 years. And really sorry if you care about security.
If you "care about security" and for some reason refuse to update your system beyond what the live image is, you should instead make your own rootfs.
No one who knows what they're doing would boot off of someone else's live image, sans updates, and pretend to be secure, even if the live image was only days old.
Not to mention that the old live images worked fine on x86_64 hardware that was new to begin with, since x86_64 is extremely backwards-compatible.
But again, the most recent live image is literally days old.
> A live image that is two years old is open to every security bug in the last two years. Good luck refuting that logic.
Update. The. Live. Image. Takes four seconds. If you care so much, it literally takes zero seconds not to use a live image, and instead bootstrap your system with xbps on another system. You aren't supposed to stay with the live image. There's no "logic" to your post.
Yeah, I retract my statement. It was my error there, and I apologize.
Not going into too much detail, but was following a lot of the drama going on for the past two years and found it odd there wasn't a release in all that time.
That said, I shouldn't get worked up or argue about things that aren't my business. I apologize.
I think sometimes, sw dependencies like openssl are too dangerous. We should have people using Peter Gutmans crypto library, or Dan Bernstein. Glomming it all into openssl was not good.
I do stuff in rfc3779 which got baked into openssl and not having it in other libraries is a pain. We partly funded the baking, so I guess we own the consequence.