9 ms·

Consider LibreSSL as default OpenSSL provider again

196 points by ori_b 5y ago

dekhn 5y ago
When I was a postdoc at Berkeley we wanted to release some open source code. I talked to the professor, who is a really smart guy. We discussed various licenses and I asked about GPL. He said he had read it and simply couldn't understand what it meant, legally speaking. He read the BSD (both types) license and it made perfect sense (same for Apache and MIT). After thinking for a while and seeing the battles and their outcomes I have concluded that GPL is in fact a liability, not a license.
- getcrunk 5y ago
  Can you explain to a noob?
  - dekhn 5y ago
    He meant that after reading it, it was unclear that it was actually a legal license that would stand up in a court of law. It's just too confusingly written. See Nelson Minar's comment at the end of this: https://web.archive.org/web/20081015194558/http://radar.oreilly.com/archives/2007/05/gplv3_clarity_a.html https://web.archive.org/web/20081015194558/http://radar.orei... Every IP lawyer I've talked to since has looked at GPL and said something pretty similar. "It's just too confusingly worded to understand as a defensible license"
    - smhenderson 5y ago
      Someone's lawyers seem to understand it better than he did, company's seem eager to settle rather go to trial when they are found to be violating it. https://en.wikipedia.org/wiki/BusyBox#GPL_lawsuits https://en.wikipedia.org/wiki/BusyBox#GPL_lawsuits https://www.pillsburylaw.com/images/content/1/6/v2/1655/A9A22185D029BBE6EAA4332F1A7249E2.pdf https://www.pillsburylaw.com/images/content/1/6/v2/1655/A9A2...
      - coldacid 5y ago
        That probably says a lot more about the optics of being sued over the GPL than legal defendability.
      - tjalfi 5y ago
        > Someone's lawyers seem to understand it better than he did, company's seem eager to settle rather go to trial when they are found to be violating it. It's often substantially cheaper to settle lawsuits than go to trial. This says more about our legal system and the American rule[0] than anything else. [0] https://en.wikipedia.org/wiki/American_rule_(attorney's_fees https://en.wikipedia.org/wiki/American_rule_(attorney's_fees)
        smhenderson 5y ago
        Well the reason I linked to the second article is because it talks about how more and more it looks like the GPL is solid and enforceable. So expense aside, as time rolls on and more cases come up it's pretty clear that defendants assume they'll lose if they are caught violating the license terms and try to fight it.
    - orra 5y ago
      That link article? It makes bold claims about the GPL being imprecise, ambiguous, and full of legal holes. But not a single example. Rhetoric, huh.
drewg123 5y ago
In addition to missing FIPS, I wonder if LibreSSL supports kTLS. That could be another reason to stick to OpenSSL. The only ssl libs that I'm aware of that support kTLS are OpenSSL, and a hack I did to golang (modeled on https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-13-and-go/ https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-1...).
- anarazel 5y ago
  The last time I checked - maybe 3-4 months ago - the ktls implementation in openssl still seemed, um, somewhat fragile. Undocumented behaviour changes, missing error handling, ...
- avhon1 5y ago
  Given that LibreSSL is natively developed for OpenBSD (and that searches turned up nothing), I strongly doubt it does. edit: Maybe the developers would be amenable to a patch, but it sounds like a substantial undertaking.
- Seirdy 5y ago
  Also worth noting that Nginx recently got support for kTLS in OpenSSL 3.x, including the quictls fork: https://mailman.nginx.org/pipermail/nginx/2021-November/061182.html https://mailman.nginx.org/pipermail/nginx/2021-November/0611... I'm happily using BoringSSL with nginx-quic but this might be enough for me to give quictls a brief look; I'm a sucker for seeing just how much perf I can squeeze out of a static file server without compromising too much on security, and this could be neat. The only other TLS lib I know of with kTLS 1.3 support is wolfSSL.
- e12e 5y ago
  The main reason for kTLS is support for dedicated tls hardware? Is that still relevant today?
  - namibj 5y ago
    If you buy a >=40Gbit/s NIC, chances are high it has an offloading engine suitable for kTLS. Much of the benefit comes from saving memory bandwidth, AFAIK.
JoshTriplett 5y ago
> It is also the opinion of the Alpine license review community that the OpenSSL 1.x license was already compatible with both GPLv2 and GPLv3 due to the system library exception: it is generally not possible to install an Alpine system without having an OpenSSL implementation, so it clearly qualifies as a system library. The text of the system library exception in GPLv2: > However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Emphasis on unless that component itself accompanies the executable. There's a long history of discussions of this clause, and many of them make the point that this exception is designed to allow FOSS projects to distribute software for proprietary OSes (e.g. link to proprietary Windows or UNIX libraries), but not for the OS distributors themselves to be able to distribute FOSS code alongside their proprietary OS. (Note that the GPLv3 broadened this exception, and no longer limits it on the basis of "unless that component itself accompanies the executable". So it's entirely possible that OpenSSL could be considered a system library for the purposes of GPLv3, while not being considered a system library for the purposes of GPLv2.)
- anthk 5y ago
  LibreSSL is the default SSL spec for OpenBSD's base, so it should be compatible with everything.
  - JoshTriplett 5y ago
    OpenBSD won't have anything under copyleft licenses anyway. The OpenSSL license has never been an issue for BSDs; it has primarily been an issue for Linux distributions and other distributors of software under copyleft licenses.
    - rubyist5eva 5y ago
      You can include BSD licensed code in GPL code, but not the other way around right?
hacker_newz 5y ago
The PKI infrastructure for a bank is on a laptop?
- cpach 5y ago
  Huh?
  - momothereal 5y ago
    I think it was meant to be a reply for: https://news.ycombinator.com/item?id=29265760 https://news.ycombinator.com/item?id=29265760
  - cosentiyes 5y ago
    I think their comment was meant for https://news.ycombinator.com/item?id=29265760 https://news.ycombinator.com/item?id=29265760
    - nqzero 5y ago
      i think that comment jumped the air gap
- toyg 5y ago
  But it's The Holy Laptop of John The Analyst, tenderly preserved in a climate-controlled vault (i.e. near the office aircon unit) since 1996. Rumor has it that its coffee stains have achieved sentience, because it's not been cleaned since John was summarily fired for gross misconduct. Its battery has long been replaced with a mains cable going through a UPS unit bought secondhand on eBay (hey, it was the 90s). It is booted only once a year, on the third week of May, when the sun hits the window of the cubicle of Bob The Security Evangelist so hard, that he actually has to stand up and go to another room.
CameronNemo 5y ago
LibreSSL also has not fired any project managers or missed any key deadlines. * Cameron snorts
david_draco 5y ago
What would be the consequences of dropping MD4 support in wpa-supplicant? Does OpenBSD not work with WPA-PSK at all or is that implemented separately?
- avhon1 5y ago
  OpenBSD does support PSK. Random excerpt here: > For standard WPA networks which use pre-shared keys (PSK), keys are configured using the "wpakey" option. [1] I think the article is saying that the new OpenSSL is the library that breaks, or makes it hard to use, MD4. [1] https://man.openbsd.org/ipw https://man.openbsd.org/ipw
  - thayne 5y ago
    I think the question is, what would break if they went forward with using OpenSSL 3 and dropped support for MD4 in wpa_supplicant?
    - avhon1 5y ago
      Educated by a about five minutes of searching and reading, my impression is that not supporting MD4 means not supporting WPA networks.
    - oynqr 5y ago
      Mschapv2 needs NTLM/MD4. Eduroam uses Mschapv2 inner authentication.
      - mbalyuzi 5y ago
        eduroam _can_ use mschapv2, but it's not mandatory. What's in the inner tunnel is up to the individual home institution and their clients.
- bjoli 5y ago
  WPA2 uses SHA1 IIRC. I havent seen a WPA network in over 10 years. I am pretty sure that code path can (and maybe should) be stripped.
rdcldrmr 5y ago
> OpenSSL developers appear to want to focus on developing new features rather than cleaning up the mess of regressions they have created with OpenSSL 3. There is so much truth contained in this one line... and it's been that way with every OpenSSL release. Being funded by Red Hat comes with a price that users sometimes end up paying. LibreSSL has zero corporate involvement but remains in very active development, with arguably much better coding practices and a very consistent release schedule that follows OpenBSD. You won't find every new or obscure feature rushed into the codebase, but (perhaps as a result of that) I have a lot more confidence in it personally. Most of the compatibility issues they had with LibreSSL before have been solved with the integration of the OpenSSL 1.1 API, which is in the newest stable version.
- deleted 5y ago
  [deleted]
- bonzini 5y ago
  > Being funded by Red Hat What funding are you referring to?
  - CameronNemo 5y ago
    I am not sure what they mean by that, but I looked into it and found their acknowledgements page: https://www.openssl.org/support/acks.html https://www.openssl.org/support/acks.html Which links to a "thanks" page: https://www.openssl.org/community/thanks.html https://www.openssl.org/community/thanks.html which says the following: We'd like to thank the following individuals and organizations who contribute to the OpenSSL project. [...] The following organizations who contribute staff time to work on the project (alphabetically): Akamai, Cryptsoft, Google, Oracle, Red Hat, Siemens, and Softing.
ori_b 5y ago
Also: https://twitter.com/ariadneconill/status/1457787938683580425 https://twitter.com/ariadneconill/status/1457787938683580425
capableweb 5y ago
Seems like this stems from https://github.com/openssl/openssl/issues/16660 https://github.com/openssl/openssl/issues/16660 which contains the full backstory and some more information. kaniini, same as Ariadne Conill who posted the issue in the linked GitLab instance, opened a issue about a regression. They felt the response from the OpenSSL team wasn't as fast as expected, and created the text that this submission is linking to. Seems expectations of a quick fix was never told about in the GitHub repository for OpenSSL, and instead the author chose to write on Twitter and in AlpineLinux GitLab about the frustrations. I can't help but to see this as a personal reaction to these events, and unsure about the merit to change it out so hastily. But, I'm not super up-to-date about things in LibreSSL/OpenSSL land so I could be wrong, it has happened before.
- stonogo 5y ago
  They ignored a crash bug for a month and a half. Nobody should have to explain to a security package maintainer that a crash bug is a priority. If I were running a distro I'd be advertising to my users that there is a problem too, so they would know that the distro is considering alternatives.
  - soraminazuki 5y ago
    Thinking about ways you can contribute would be far more productive than fantasizing about what the best possible position to be in would be when criticizing the project. Judging from the issues and commit logs, the OpenSSL project looks very busy and I'd guess they'd gladly accept genuine help.
- ThatGeoGuy 5y ago
  Ariadne actually answers this in that thread: https://github.com/openssl/openssl/issues/16660#issuecomment-967315484 https://github.com/openssl/openssl/issues/16660#issuecomment... I'll quote the section: "Given that the OpenSSL 3 migration had an outcome where our contingency plan came into effect, I believe it to be the most prudent course of action to evaluate all possible options before committing to trying the OpenSSL 3 migration again, such an evaluation would be required by the TSC anyway." The Alpine project operates independently from OpenSSL, so it's no surprise they published their own report to discuss their own timelines. I'm not sure I can attest to this being a "personal" reaction from my interpretation. Instead, this seems rather like the Alpine project's reaction to their own internal deadlines. Tossing out OpenSSL may appear flippant from a distance, but getting SSL correct for their own releases and finding projects that want to work alongside them (as LibreSSL is supposedly responsive towards doing) should be a priority if you're in charge of getting this work ticket over the line. Of course, the wording and general attitude towards OpenSSL developers can be interpreted however you want, but I don't see this as outright hostility or a personal reaction so much as "this ticket was left for over a month, and our project needs to make forward progress."
snvzz 5y ago
In a sane world, the moment libressl became a thing, we should all have switched to it. Instead, we chose to fund the known-bad project, as if just throwing money at a problem was going to solve it. Now, we have hindsight. Perhaps it is not too late to switch?
- tptacek 5y ago
  This is, respectfully, horseshit. OpenSSL gained (deservedly) a reputation for insecurity around the time of Heartbleed, but its governance and maintenance changed radically in the years immediately following. I would trust OpenSSL more than I would trust LibreSSL at this point. Certainly, it's one of the most aggressively surveilled security codebases on the Internet.
  - snvzz 5y ago
    OpenSSL still has a long way to go to earn my trust. OpenBSD (which maintain LibreSSL) have had my trust for a long time already. As almost everybody else, I do rely on a lot of projects they maintain, and they have yet to disappoint me.
klardotsh 5y ago
It's fun to try to keep track of the SSL implementations distributions use/allow over time. Void, for example, started on OpenSSL, moved to LibreSSL, and then moved back [1]. Gentoo has always been OpenSSL by default, had serious motion towards enabling LibreSSL as a first class citizen, and then backed out of that effort [2]. And now Alpine is looking at their second switch from OpenSSL to LibreSSL. I'm a little bit amazed this hasn't caused even more stress than it has for cases like building V8/Chromium; this back and forth stuff is going to get hard to keep track of (for application developers, at least). [1] https://voidlinux.org/news/2021/02/OpenSSL.html https://voidlinux.org/news/2021/02/OpenSSL.html [2] https://www.gentoo.org/support/news-items/2021-01-05-libressl-support-discontinued.html https://www.gentoo.org/support/news-items/2021-01-05-libress...
- arghwhat 5y ago
  That Alpine is trying again suggests that even multiple attempts at migrating away is ultimately less stressful than remaining on OpenSSL...
  - R0b0t1 5y ago
    There's people still trying on Gentoo, it's just not as easy as it immediately looks.
- orra 5y ago
  > I'm a little bit amazed this hasn't caused even more stress than it has for cases like building V8/Chromium Distros seem to have shifted towards using bundled libraries for browsers. In this case, Chromium uses BoringSSL. It's too much effort to diverge from the upstream browsers. Besides, security teams for browsers tend to be better staffed than for distros.
  - XorNot 5y ago
    Kind of wish we'd move TLS into the kernel at this point. Centralize the developer attention on it, and acknowledge that if the kernel is going to provide TCP sockets, it should provide all the tooling needed to secure those sockets as well. It's not a perfectly logical argument, but kernels get patched and upgraded more often then almost any other software.
gigatexal 5y ago
Or … they could contribute to the OpenSSL project. Didn’t we find out a few years ago that the project was underfunded and d very few maintainers. Seems like they could benefit from help and licensing aside could have a better chance getting it working 100% with apk and alpine.

196 points by ori_b 5y ago

When I was a postdoc at Berkeley we wanted to release some open source code. I talked to the professor, who is a really smart guy. We discussed various licenses and I asked about GPL. He said he had read it and simply couldn't understand what it meant, legally speaking. He read the BSD (both types) license and it made perfect sense (same for Apache and MIT). After thinking for a while and seeing the battles and their outcomes I have concluded that GPL is in fact a liability, not a license.

getcrunk 5y ago
Can you explain to a noob?
- dekhn 5y ago
  He meant that after reading it, it was unclear that it was actually a legal license that would stand up in a court of law. It's just too confusingly written. See Nelson Minar's comment at the end of this: https://web.archive.org/web/20081015194558/http://radar.oreilly.com/archives/2007/05/gplv3_clarity_a.html https://web.archive.org/web/20081015194558/http://radar.orei... Every IP lawyer I've talked to since has looked at GPL and said something pretty similar. "It's just too confusingly worded to understand as a defensible license"
  - smhenderson 5y ago
    Someone's lawyers seem to understand it better than he did, company's seem eager to settle rather go to trial when they are found to be violating it. https://en.wikipedia.org/wiki/BusyBox#GPL_lawsuits https://en.wikipedia.org/wiki/BusyBox#GPL_lawsuits https://www.pillsburylaw.com/images/content/1/6/v2/1655/A9A22185D029BBE6EAA4332F1A7249E2.pdf https://www.pillsburylaw.com/images/content/1/6/v2/1655/A9A2...
    - coldacid 5y ago
      That probably says a lot more about the optics of being sued over the GPL than legal defendability.
    - tjalfi 5y ago
      > Someone's lawyers seem to understand it better than he did, company's seem eager to settle rather go to trial when they are found to be violating it. It's often substantially cheaper to settle lawsuits than go to trial. This says more about our legal system and the American rule[0] than anything else. [0] https://en.wikipedia.org/wiki/American_rule_(attorney's_fees https://en.wikipedia.org/wiki/American_rule_(attorney's_fees)
      - smhenderson 5y ago
        Well the reason I linked to the second article is because it talks about how more and more it looks like the GPL is solid and enforceable. So expense aside, as time rolls on and more cases come up it's pretty clear that defendants assume they'll lose if they are caught violating the license terms and try to fight it.
  - orra 5y ago
    That link article? It makes bold claims about the GPL being imprecise, ambiguous, and full of legal holes. But not a single example. Rhetoric, huh.

drewg123 5y ago

In addition to missing FIPS, I wonder if LibreSSL supports kTLS. That could be another reason to stick to OpenSSL. The only ssl libs that I'm aware of that support kTLS are OpenSSL, and a hack I did to golang (modeled on https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-13-and-go/ https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-1...).

anarazel 5y ago
The last time I checked - maybe 3-4 months ago - the ktls implementation in openssl still seemed, um, somewhat fragile. Undocumented behaviour changes, missing error handling, ...
avhon1 5y ago
Given that LibreSSL is natively developed for OpenBSD (and that searches turned up nothing), I strongly doubt it does. edit: Maybe the developers would be amenable to a patch, but it sounds like a substantial undertaking.
Seirdy 5y ago
Also worth noting that Nginx recently got support for kTLS in OpenSSL 3.x, including the quictls fork: https://mailman.nginx.org/pipermail/nginx/2021-November/061182.html https://mailman.nginx.org/pipermail/nginx/2021-November/0611... I'm happily using BoringSSL with nginx-quic but this might be enough for me to give quictls a brief look; I'm a sucker for seeing just how much perf I can squeeze out of a static file server without compromising too much on security, and this could be neat. The only other TLS lib I know of with kTLS 1.3 support is wolfSSL.
e12e 5y ago
The main reason for kTLS is support for dedicated tls hardware? Is that still relevant today?
- namibj 5y ago
  If you buy a >=40Gbit/s NIC, chances are high it has an offloading engine suitable for kTLS. Much of the benefit comes from saving memory bandwidth, AFAIK.

JoshTriplett 5y ago

> It is also the opinion of the Alpine license review community that the OpenSSL 1.x license was already compatible with both GPLv2 and GPLv3 due to the system library exception: it is generally not possible to install an Alpine system without having an OpenSSL implementation, so it clearly qualifies as a system library. The text of the system library exception in GPLv2: > However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Emphasis on unless that component itself accompanies the executable. There's a long history of discussions of this clause, and many of them make the point that this exception is designed to allow FOSS projects to distribute software for proprietary OSes (e.g. link to proprietary Windows or UNIX libraries), but not for the OS distributors themselves to be able to distribute FOSS code alongside their proprietary OS. (Note that the GPLv3 broadened this exception, and no longer limits it on the basis of "unless that component itself accompanies the executable". So it's entirely possible that OpenSSL could be considered a system library for the purposes of GPLv3, while not being considered a system library for the purposes of GPLv2.)

anthk 5y ago
LibreSSL is the default SSL spec for OpenBSD's base, so it should be compatible with everything.
- JoshTriplett 5y ago
  OpenBSD won't have anything under copyleft licenses anyway. The OpenSSL license has never been an issue for BSDs; it has primarily been an issue for Linux distributions and other distributors of software under copyleft licenses.
  - rubyist5eva 5y ago
    You can include BSD licensed code in GPL code, but not the other way around right?

hacker_newz 5y ago

The PKI infrastructure for a bank is on a laptop?

cpach 5y ago
Huh?
- momothereal 5y ago
  I think it was meant to be a reply for: https://news.ycombinator.com/item?id=29265760 https://news.ycombinator.com/item?id=29265760
- cosentiyes 5y ago
  I think their comment was meant for https://news.ycombinator.com/item?id=29265760 https://news.ycombinator.com/item?id=29265760
  - nqzero 5y ago
    i think that comment jumped the air gap
toyg 5y ago
But it's The Holy Laptop of John The Analyst, tenderly preserved in a climate-controlled vault (i.e. near the office aircon unit) since 1996. Rumor has it that its coffee stains have achieved sentience, because it's not been cleaned since John was summarily fired for gross misconduct. Its battery has long been replaced with a mains cable going through a UPS unit bought secondhand on eBay (hey, it was the 90s). It is booted only once a year, on the third week of May, when the sun hits the window of the cubicle of Bob The Security Evangelist so hard, that he actually has to stand up and go to another room.

CameronNemo 5y ago

LibreSSL also has not fired any project managers or missed any key deadlines. * Cameron snorts

david_draco 5y ago

What would be the consequences of dropping MD4 support in wpa-supplicant? Does OpenBSD not work with WPA-PSK at all or is that implemented separately?

avhon1 5y ago
OpenBSD does support PSK. Random excerpt here: > For standard WPA networks which use pre-shared keys (PSK), keys are configured using the "wpakey" option. [1] I think the article is saying that the new OpenSSL is the library that breaks, or makes it hard to use, MD4. [1] https://man.openbsd.org/ipw https://man.openbsd.org/ipw
- thayne 5y ago
  I think the question is, what would break if they went forward with using OpenSSL 3 and dropped support for MD4 in wpa_supplicant?
  - avhon1 5y ago
    Educated by a about five minutes of searching and reading, my impression is that not supporting MD4 means not supporting WPA networks.
  - oynqr 5y ago
    Mschapv2 needs NTLM/MD4. Eduroam uses Mschapv2 inner authentication.
    - mbalyuzi 5y ago
      eduroam _can_ use mschapv2, but it's not mandatory. What's in the inner tunnel is up to the individual home institution and their clients.
bjoli 5y ago
WPA2 uses SHA1 IIRC. I havent seen a WPA network in over 10 years. I am pretty sure that code path can (and maybe should) be stripped.

rdcldrmr 5y ago

> OpenSSL developers appear to want to focus on developing new features rather than cleaning up the mess of regressions they have created with OpenSSL 3. There is so much truth contained in this one line... and it's been that way with every OpenSSL release. Being funded by Red Hat comes with a price that users sometimes end up paying. LibreSSL has zero corporate involvement but remains in very active development, with arguably much better coding practices and a very consistent release schedule that follows OpenBSD. You won't find every new or obscure feature rushed into the codebase, but (perhaps as a result of that) I have a lot more confidence in it personally. Most of the compatibility issues they had with LibreSSL before have been solved with the integration of the OpenSSL 1.1 API, which is in the newest stable version.

deleted 5y ago
[deleted]
bonzini 5y ago
> Being funded by Red Hat What funding are you referring to?
- CameronNemo 5y ago
  I am not sure what they mean by that, but I looked into it and found their acknowledgements page: https://www.openssl.org/support/acks.html https://www.openssl.org/support/acks.html Which links to a "thanks" page: https://www.openssl.org/community/thanks.html https://www.openssl.org/community/thanks.html which says the following: We'd like to thank the following individuals and organizations who contribute to the OpenSSL project. [...] The following organizations who contribute staff time to work on the project (alphabetically): Akamai, Cryptsoft, Google, Oracle, Red Hat, Siemens, and Softing.

ori_b 5y ago

Also: https://twitter.com/ariadneconill/status/1457787938683580425 https://twitter.com/ariadneconill/status/1457787938683580425

capableweb 5y ago

Seems like this stems from https://github.com/openssl/openssl/issues/16660 https://github.com/openssl/openssl/issues/16660 which contains the full backstory and some more information. kaniini, same as Ariadne Conill who posted the issue in the linked GitLab instance, opened a issue about a regression. They felt the response from the OpenSSL team wasn't as fast as expected, and created the text that this submission is linking to. Seems expectations of a quick fix was never told about in the GitHub repository for OpenSSL, and instead the author chose to write on Twitter and in AlpineLinux GitLab about the frustrations. I can't help but to see this as a personal reaction to these events, and unsure about the merit to change it out so hastily. But, I'm not super up-to-date about things in LibreSSL/OpenSSL land so I could be wrong, it has happened before.

stonogo 5y ago
They ignored a crash bug for a month and a half. Nobody should have to explain to a security package maintainer that a crash bug is a priority. If I were running a distro I'd be advertising to my users that there is a problem too, so they would know that the distro is considering alternatives.
- soraminazuki 5y ago
  Thinking about ways you can contribute would be far more productive than fantasizing about what the best possible position to be in would be when criticizing the project. Judging from the issues and commit logs, the OpenSSL project looks very busy and I'd guess they'd gladly accept genuine help.
ThatGeoGuy 5y ago
Ariadne actually answers this in that thread: https://github.com/openssl/openssl/issues/16660#issuecomment-967315484 https://github.com/openssl/openssl/issues/16660#issuecomment... I'll quote the section: "Given that the OpenSSL 3 migration had an outcome where our contingency plan came into effect, I believe it to be the most prudent course of action to evaluate all possible options before committing to trying the OpenSSL 3 migration again, such an evaluation would be required by the TSC anyway." The Alpine project operates independently from OpenSSL, so it's no surprise they published their own report to discuss their own timelines. I'm not sure I can attest to this being a "personal" reaction from my interpretation. Instead, this seems rather like the Alpine project's reaction to their own internal deadlines. Tossing out OpenSSL may appear flippant from a distance, but getting SSL correct for their own releases and finding projects that want to work alongside them (as LibreSSL is supposedly responsive towards doing) should be a priority if you're in charge of getting this work ticket over the line. Of course, the wording and general attitude towards OpenSSL developers can be interpreted however you want, but I don't see this as outright hostility or a personal reaction so much as "this ticket was left for over a month, and our project needs to make forward progress."

snvzz 5y ago

In a sane world, the moment libressl became a thing, we should all have switched to it. Instead, we chose to fund the known-bad project, as if just throwing money at a problem was going to solve it. Now, we have hindsight. Perhaps it is not too late to switch?

tptacek 5y ago
This is, respectfully, horseshit. OpenSSL gained (deservedly) a reputation for insecurity around the time of Heartbleed, but its governance and maintenance changed radically in the years immediately following. I would trust OpenSSL more than I would trust LibreSSL at this point. Certainly, it's one of the most aggressively surveilled security codebases on the Internet.
- snvzz 5y ago
  OpenSSL still has a long way to go to earn my trust. OpenBSD (which maintain LibreSSL) have had my trust for a long time already. As almost everybody else, I do rely on a lot of projects they maintain, and they have yet to disappoint me.

klardotsh 5y ago

It's fun to try to keep track of the SSL implementations distributions use/allow over time. Void, for example, started on OpenSSL, moved to LibreSSL, and then moved back [1]. Gentoo has always been OpenSSL by default, had serious motion towards enabling LibreSSL as a first class citizen, and then backed out of that effort [2]. And now Alpine is looking at their second switch from OpenSSL to LibreSSL. I'm a little bit amazed this hasn't caused even more stress than it has for cases like building V8/Chromium; this back and forth stuff is going to get hard to keep track of (for application developers, at least). [1] https://voidlinux.org/news/2021/02/OpenSSL.html https://voidlinux.org/news/2021/02/OpenSSL.html [2] https://www.gentoo.org/support/news-items/2021-01-05-libressl-support-discontinued.html https://www.gentoo.org/support/news-items/2021-01-05-libress...

arghwhat 5y ago
That Alpine is trying again suggests that even multiple attempts at migrating away is ultimately less stressful than remaining on OpenSSL...
- R0b0t1 5y ago
  There's people still trying on Gentoo, it's just not as easy as it immediately looks.
orra 5y ago
> I'm a little bit amazed this hasn't caused even more stress than it has for cases like building V8/Chromium Distros seem to have shifted towards using bundled libraries for browsers. In this case, Chromium uses BoringSSL. It's too much effort to diverge from the upstream browsers. Besides, security teams for browsers tend to be better staffed than for distros.
- XorNot 5y ago
  Kind of wish we'd move TLS into the kernel at this point. Centralize the developer attention on it, and acknowledge that if the kernel is going to provide TCP sockets, it should provide all the tooling needed to secure those sockets as well. It's not a perfectly logical argument, but kernels get patched and upgraded more often then almost any other software.

gigatexal 5y ago

Or … they could contribute to the OpenSSL project. Didn’t we find out a few years ago that the project was underfunded and d very few maintainers. Seems like they could benefit from help and licensing aside could have a better chance getting it working 100% with apk and alpine.