[HN Gopher] Consider LibreSSL as default OpenSSL provider again
___________________________________________________________________
Consider LibreSSL as default OpenSSL provider again
Author : ori_b
Score : 143 points
Date : 2021-11-18 14:38 UTC (8 hours ago)
(HTM) web link (gitlab.alpinelinux.org)
(TXT) w3m dump (gitlab.alpinelinux.org)
| drewg123 wrote:
| 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-1...).
| e12e wrote:
| The main reason for kTLS is support for dedicated tls hardware?
| Is that still relevant today?
| anarazel wrote:
| 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 wrote:
| 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 wrote:
| 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/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.
| ori_b wrote:
| Also:
| https://twitter.com/ariadneconill/status/1457787938683580425
| hacker_newz wrote:
| The PKI infrastructure for a bank is on a laptop?
| toyg wrote:
| 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.
| cpach wrote:
| Huh?
| momothereal wrote:
| I think it was meant to be a reply for:
| https://news.ycombinator.com/item?id=29265760
| cosentiyes wrote:
| I think their comment was meant for
| https://news.ycombinator.com/item?id=29265760
| nqzero wrote:
| i think that comment jumped the air gap
| JoshTriplett wrote:
| > 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 wrote:
| LibreSSL is the default SSL spec for OpenBSD's base, so it
| should be compatible with everything.
| JoshTriplett wrote:
| 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.
| krylon wrote:
| AFAIR, OpenBSD has included the GPL-licensed gcc for a long
| time. They have a clear preference for more permissive
| license, but it would seem the GPL is not a problem as
| such, the OpenBSD developers just prefer more liberal
| alternatives where possible.
|
| I'm not taking sides here, the OpenBSD developers have
| famously stopped supporting hardware when the vendors did
| not supply documentation under acceptable conditions. They
| obviously are very serious about the "Open" part.
| anthk wrote:
| OpenBSD discarded base gcc. Now they are pro-ISC
| everywhere.
|
| They included gcc for convenience in some architectures.
| krylon wrote:
| I know, but they included it for a pretty long time, so I
| think distributing GPL code as part of a BSD project is
| kosher, legally speaking. (Same goes for FreeBSD,
| although they, too, replaced gcc with clang some time
| ago.)
| chasil wrote:
| Clang is now used on the x86-64 variant of OpenBSD.
|
| I'm fairly confident that gcc is still available in the
| ports collection.
|
| On architectures that clang doesn't support, it's
| (likely) still gcc.
| krylon wrote:
| I know. Last time I checked, gcc still was the default C
| compiler on architectures clang did not support, but it
| was a couple years ago, and they discontinued a few
| architectures since (vax, alpha, probably others?).
|
| Yes, gcc is still available through ports/packages, but
| the point was if it's okay to distribute GPL code as part
| of the base system if the base as a whole is BSD/MIT
| licensed.
| rubyist5eva wrote:
| You can include BSD licensed code in GPL code, but not the
| other way around right?
| danudey wrote:
| This is correct. The typical restrictions on BSD code
| are:
|
| 1. If you distribute source code you need to retain the
| copyright notice, the license conditions, and the
| disclaimer
|
| 2. If you distribute binaries you must include those in
| the documentation
|
| 3. (sometimes) You can't use the contributors to promote
| your software (e.g. "Powered by the fantastic LibreSSL
| library!")
| bonetruck wrote:
| Correct.
| torstenvl wrote:
| Incorrect. You may distribute BSD-licensed code alongside
| GPL code, and you can release your modifications to a
| BSD-licensed work under the GPL, but there is _no
| possibility_ of subsuming the BSD-licensed code _in_ the
| GPL-licensed code. Any attempt to do so would constitute
| copyright infringement against the original authors.
|
| An example may be illustrative. If your GPL project uses
| a BSD-licensed single-header-file library, and you
| distribute that library's source with your source,
| downstream users are free to take that library from your
| source repository and use it for their own purposes
| without abiding by the GPL. Nor may you change the
| license and copyright notice in the header file in order
| to claim that the library is GPL, because if you do so
| you will be violating the conditions of the BSD license,
| leaving you with no right to use or distribute the
| software at all.
| bscphil wrote:
| You're pulling at straws here.
|
| If I'm writing a program under GPL, and I want to
| incorporate a component with a BSD license, I can do that
| and continue to license the entire program to my users
| under the GPL.
|
| If I'm writing a program under BSD, and I want to
| incorporate a component with a GPL license, I _can 't_ do
| that and continue to license the entire program to my
| users under the BSD. That's the difference, and surely
| that's what the OP is referring to.
|
| Suppose someone comes along and finds my program, and
| wants to modify it and release it without providing the
| source. Before, when I could license the whole program as
| BSD, the could do that. After I incorporated a single
| file's worth of GPL code, they can't do that. Because
| it's no longer possible for me to license my program as
| BSD.
|
| Also, note that there's absolutely no guarantee that
| users can "take that library from your source repository
| and use it for their own purposes without abiding by the
| GPL". I am under no obligation to provide a BSD-licensed
| copy of the original library. If I make modifications to
| the library before I push it to my repository, I _do_
| still have to keep the copyright notice intact, but I am
| not providing anyone with a BSD library. My modified
| version of it is _only_ GPL.
| torstenvl wrote:
| You are laboring under utterly false beliefs. Please
| trust lawyers with the law. Thanks.
| pessimizer wrote:
| As far as I can tell, you're saying that if a piece of
| GPL software includes unchanged BSD code, anyone can
| download that unchanged BSD code from the repository for
| the GPL'd piece of software and use it under the BSD
| license.
|
| This is not a situation that anyone is discussing.
|
| What is being said is that I can take a piece of BSD
| code, modify it as I see fit, and relicense the
| assemblage as GPL (or as my personal property for that
| matter) as long as I include the BSD license and
| acknowledgements when I redistribute it. I cannot take a
| piece of GPL code, modify it as I see fit, and relicense
| it as BSD. If you disagree with this, explain why, but
| don't bring up some situation that is as vanishingly rare
| as to possibly have never happened. If you're desperate
| for a piece of BSD code, and the only place to get it is
| within the repo of a GPLed piece of software that
| includes it untouched, nobody is going to claim that code
| becomes GPLed from being distributed _alongside_ GPLed
| software. But if I go through that code and add the
| prefix "GPLisbetter-" to every variable name, can you
| use it under BSD?
| torstenvl wrote:
| > _This is not a situation that anyone is discussing._
|
| It's exactly the situation that was articulated.
|
| > _What is being said is that I can take a piece of BSD
| code, modify it as I see fit, and relicense the
| assemblage as GPL_
|
| That is probably false. The BSD code itself cannot be
| relicensed, since nothing grants you that permission.
| Courts have not expanded the idea of compilation
| copyright to software linking, so far as I know, so that
| is an open question.
|
| > _if I go through that code and add the prefix
| "GPLisbetter-" to every variable name, can you use it
| under BSD?_
|
| Yes.
| JoshTriplett wrote:
| BSD-licensed code yes. But LibreSSL and OpenSSL (pre-3.0)
| are not under a BSD license; they're under a custom
| license that's GPL-incompatible.
| snvzz wrote:
| 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?
| CameronNemo wrote:
| _LibreSSL also has not fired any project managers or missed any
| key deadlines._
|
| * Cameron snorts
| david_draco wrote:
| 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?
| bjoli wrote:
| 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.
| avhon1 wrote:
| 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
| thayne wrote:
| 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 wrote:
| Educated by a about five minutes of searching and reading,
| my impression is that not supporting MD4 means not
| supporting WPA networks.
| oynqr wrote:
| Mschapv2 needs NTLM/MD4. Eduroam uses Mschapv2 inner
| authentication.
| rdcldrmr wrote:
| > 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]
| bonzini wrote:
| > Being funded by Red Hat
|
| What funding are you referring to?
| klardotsh wrote:
| 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 [2]
| https://www.gentoo.org/support/news-items/2021-01-05-libress...
| arghwhat wrote:
| That Alpine is trying _again_ suggests that even multiple
| attempts at migrating away is ultimately less stressful than
| remaining on OpenSSL...
| orra wrote:
| > 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.
| dekhn wrote:
| 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 wrote:
| Can you explain to a noob?
| dekhn wrote:
| 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/20081
| 015194558/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 wrote:
| 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://www.pillsburylaw.com/images/content/1/6/v2/1655/A9A
| 2...
| coldacid wrote:
| That probably says a lot more about the optics of being
| sued over the GPL than legal defendability.
| tjalfi wrote:
| > 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)
| orra wrote:
| 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.
| capableweb wrote:
| Seems like this stems from
| 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.
| lonjil wrote:
| Ehh, it doesn't seem very hasty to me. The proposal is for
| Alpine 3.17 or 3.18, which are 1 and 1.5 years away
| respectively. That's plenty of time to consider the pros and
| cons, try it, and revert if it ends up being a poor choice.
|
| > Seems like this stems from
| https://github.com/openssl/openssl/issues/16660 which contains
| the full backstory and some more information.
|
| I wouldn't call that the "full backstory", since it is only
| about a single issue outlined in this proposal. Though she does
| explain that fact in that GitHub thread too, and also why
| they're looking into alternatives:
|
| > 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.
|
| > and instead the author chose to write on Twitter and in
| AlpineLinux GitLab about the frustrations.
|
| Eh, I wouldn't read too much into short twitter vents. As for
| the Alpine Linux GitLab, well, she's the head of Alpine's
| security team and a member of the TSC, so coming up with
| proposals as for what should be investigated w.r.t. security
| critical packages is one of the things she's supposed to be
| doing.
| stonogo wrote:
| 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.
| ThatGeoGuy wrote:
| Ariadne actually answers this in that thread:
| 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."
___________________________________________________________________
(page generated 2021-11-18 23:01 UTC)