Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, 29 Dec 2020 23:34:36 + Peter Stuge wrote: > David Seifert wrote: > > > Maybe because it is so well-known that monoculture is harmful per se, > > > which is why the commitment to choice in Gentoo is very valuable. > > > > > > Further, LibreSSL comes out of the OpenBSD project, which has a good > > > reputation on code quality. > > > > Like strong-arming 99% of the users of OpenSSH because they were > > unwilling to port to the OpenSSL 1.1 API, fully well knowing that most > > of the OpenSSH consuming world doesn't actually use libressl? How is > > explicitly tying OpenSSH to libressl not a form of monoculture? > > Now we're properly off-topic :) but considering that OpenSSH is developed > for OpenBSD and that openssh-portable is merely provided as a service to > other systems it's easy to understand why OpenSSH (remember, part of OpenBSD) > uses the libressl API for crypto, and why the -portable team is not so keen > on maintaining patches for other crypto providers. Another example is systemd > binding tightly to Linux. In both cases it's understandable, but also quite > unfortunate; better portability would be better. I don't have any strong opinions on either side of this argument, I have 1 machine on LibreSSL that I would need to switch, but that is not really a major issue for me. As the person who has been doing a large percentage of the OpenSSH ebuild maintenance for a couple of years now I feel I should mention that while it was the case that OpenSSH would not work with OpenSSL 1.1+ without a (rather large) patch in the past, that has not been the case for some time now. Modern OpenSSH versions work fine with modern OpenSSL versions.
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Excerpt from MichaŠGórny and previous post: > > Further, LibreSSL comes out of the OpenBSD project, which has a good > > reputation on code quality. > I could buy that if it actually said anything about LibreSSL code > quality. So far you're guessing that it might or might not, especially > given it is forked from an apparently 'inferior quality' code. > However, I do have serious doubts about LibreSSL quality given that: > 1. Non-OpenBSD systems are not first class citizens, as you yourself > pointed out. > 2. The library is an intrusive replacement for OpenSSL. In the default > setup, it is neither co-installable with OpenSSL, nor a drop-in > replacement. > 3. The upstream declares OpenSSL version constants pretty randomly, > without actually matching OpenSSL API. > 4. The upstream has actively tried to force people into using their > product by tight coupling and forced incompatibility. > 5. Apparently nobody is issuing CVEs for LibreSSL while > the vulnerabilities clearly do happen. My limited experience with OpenBSD does not give credence to their code quality. Latest experience was from liveusb-openbsd.sourceforge.net. I was able to download the image and write to 64 GB USB stick. I managed to get it to boot, but couldn't find my way around. It couldn't read my GPT-partitioned hard drive, and I was not about to take big risks regarding my data. OpenBSD fdisk is quite primitive compared to NetBSD (gpt), FreeBSD (gpart), Linux (gdisk: also available for FreeBSD, Windows and macOS). OpenBSD seems to have dubious compatibility with NetBSD, FreeBSD and Linux software packages, and is not good at peaceful coexistence with NetBSD, FreeBSD, Linux and probably other OSes on the hard drive. I looked in NetBSD pkgsrc, FreeBSD ports, Gentoo portage, and Void Linux packages, and libressl was there, which is not to say how compatible it is or how much patching is needed. Tom
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On 12/29/20 6:06 PM, David Seifert wrote: > > If you want to provide an alternative, you have to subsume the API, not > make it superficially compatible, only to find out that the you need to > mask out a ton of stuff with macros. Agreed. If libressl hadn't failed on this point, we would not be having this conversation. They promised it would be API compatible and it started that way, but not anymore. This became annoying even to me with my other packages like stunnel, where with every bump I had to create a new patch with macros based on versions. This is not something we want to saddle the rest of Gentoo with. Nor do we want to burden upstream teams to have to follow libressl's insanity. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On 12/29/20 5:41 PM, Peter Stuge wrote: > Michał Górny wrote: >>> I would be happier if some other developers were able and willing to >>> participate actively in the LibreSSL project. >> >> But why would they do that? What I'm really missing in all the replies >> is a single reason why LibreSSL would be better for anyone. > > Maybe because it is so well-known that monoculture is harmful per se, > which is why the commitment to choice in Gentoo is very valuable. > > Further, LibreSSL comes out of the OpenBSD project, which has a good > reputation on code quality. > I am sympathetic to not degrading into a monoculture. If I would characterize my contribution to Gentoo over the years it would be "alt-everything". The reason being that competition between alternatives is a good thing and time will tell which way is best. But <- here's the "but" At some point a particular path may have to be dropped because it just doesn't provide any clear advantages. There was nothing wrong with adding libressl as an alternative in 2014 since it had promise. And now, years later, I see nothing wrong with removing it. It hasn't delivered. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
> > a) The two cannot be installed concurrently. To fix that would require > > even > > more hacks. > > As we've discussed in another part of the thread, that's not really true. > Both can for sure be installed, just not in the same place and/or > with same names. Exactly that is what would require even more hacks. Given how many different and more or less hackish build systems exist in the Gentoo tree, this is just not feasible. > > -> all relevant ssl consumers on the user's system must be linked against > > the one selected > > Also not the case. Considering the two installed in different paths > with same names it's still easy for consumers to use one or the other > with -rpath at link time. Dito... Please remember, the point is to keep this somewhat maintainable. > > c) If a single package that the user wants to install is not "fixed" for > > one ssl library, it blocks that option for all packages. > > Please think of a libressl ebuild in a new way. Well, if it just drops the library somewhere where nothing can use it... that can for sure be done, but also does not really help anyone. > > I guess if you can come up with a solution that > > * provides secure usage of the libraries, > > * provides choice to the user, and > > * doesn't lead to unupgradeable systems or unresolvable dependencies > > we'd all be happier. So far we haven't found one. > > Right! I think letting a libressl ebuild install only libtls could be a > good start, because it provides a stable situation, without risking > conflicts. Would you agree? No idea to be honest, and not much opinion on this. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice)
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Wed, 2020-12-30 at 11:41 +0100, m1027 wrote: > mgorny: > > > On Tue, 2020-12-29 at 16:12 +0100, Toralf Förster wrote: > > > On 12/29/20 2:57 PM, m1027 wrote: > > > > - removing libressl, installing openssl, maybe wget then, followed > > > > by the rest? > > > remove is sufficient b/c emerge then immediately advices a > > > @preserved-rebuild - at least that's the way it works here at the > > > tinderbox (in the opposite direction FWIW) > > > > > > > I'm not sure if you meant it but it reads as if you were talking about > > removing the package. This is incorrect. > > > > You need to disable the USE flag and then --changed-use (or --newuse) > > rebuild everything with the flag. If the depgraph is clean, emerge > > should happily trigger the rebuild along with automatic replacement of > > dev-libs/libressl with dev-libs/openssl. > > > > However, it's a good idea to run the same command with --fetchonly > > first, to make sure that all distfiles are in place, in case wget got > > broken in the process. > > It might not be the place to discuss emerge dependency details here, > take it as some initial feedback on the transition from libressl to > openssl. > > The general way to go seems indeed: > > - remove libressl from USE flags, also adjusting curl_ssl > - initial emerge ... --fetchonly: to my surprise not always required > - emerge -autDUN @world > - finally the usual @preserved-rebuild I'm surprised this is necessary. -N should have rebuilt everything, unless: 1) you had some packages installed that are no longer in @world depgraph, or 2) packages have automagic dependencies. If you see things like this, it's worth investigating and reporting bugs if it's 2. > - On some systems another @world update revealed again a lot > - This also worked over ssh > > The systems I tried so far > > - 2x Gnome desktop systems, close to the USE defaults, went smoothly > - 1x Raspberry Pi over ssh: still working, ;-) okay so far > - 1x Developer system with some smaller issues > > The issues I had: > > - hostapd: when with +internal-tls, some build issue with > libtommath; when with -internal-tls it required openssl -bindist; > I did not investigate, just uninstalled hostapd yet > > - openssl+bind+openssh: conflict triggered to do +/-bindist for > openssl; solution was -bindist everywhere (see other posts on > bindist already) As mentioned somewhere else in this thread, USE=bindist is going to be revisited in the next few days, since some significant patents expire by 2021. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
mgorny: > On Tue, 2020-12-29 at 16:12 +0100, Toralf Förster wrote: > > On 12/29/20 2:57 PM, m1027 wrote: > > > - removing libressl, installing openssl, maybe wget then, followed > > > by the rest? > > remove is sufficient b/c emerge then immediately advices a > > @preserved-rebuild - at least that's the way it works here at the > > tinderbox (in the opposite direction FWIW) > > > > I'm not sure if you meant it but it reads as if you were talking about > removing the package. This is incorrect. > > You need to disable the USE flag and then --changed-use (or --newuse) > rebuild everything with the flag. If the depgraph is clean, emerge > should happily trigger the rebuild along with automatic replacement of > dev-libs/libressl with dev-libs/openssl. > > However, it's a good idea to run the same command with --fetchonly > first, to make sure that all distfiles are in place, in case wget got > broken in the process. It might not be the place to discuss emerge dependency details here, take it as some initial feedback on the transition from libressl to openssl. The general way to go seems indeed: - remove libressl from USE flags, also adjusting curl_ssl - initial emerge ... --fetchonly: to my surprise not always required - emerge -autDUN @world - finally the usual @preserved-rebuild - On some systems another @world update revealed again a lot - This also worked over ssh The systems I tried so far - 2x Gnome desktop systems, close to the USE defaults, went smoothly - 1x Raspberry Pi over ssh: still working, ;-) okay so far - 1x Developer system with some smaller issues The issues I had: - hostapd: when with +internal-tls, some build issue with libtommath; when with -internal-tls it required openssl -bindist; I did not investigate, just uninstalled hostapd yet - openssl+bind+openssh: conflict triggered to do +/-bindist for openssl; solution was -bindist everywhere (see other posts on bindist already) - old android-tools-6.0.1_p79: build issue mentioning ssl; not ivestigated further, just uninstalled Thanks
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Wed, 2020-12-30 at 09:08 +0100, Marcel Schilling wrote: > On Tue, Dec 29, 2020 at 11:31:32PM +0100, Michał Górny wrote: > > What I'm really missing in all the replies is a single reason why > > LibreSSL would be better for anyone. Not 'it's an alternative', not > > 'I don't trust' but a real proper, verifiable argument 'LibreSSL is > > better in this regard'. > > I guess that is due the fact that you dismiss arguments that are valid > reasons for others (incl. me) but apparently not sufficient for you, > like my situation where 'It works on all my systems, and switching would > mean work for me and at least a risk of downtimes'. I don't dismiss that. If I had, I wouldn't be bothering with the whole discussion and just kill it. I just draw a different conclusion than you do. Having systems that do work with LibreSSL today doesn't guarantee the same for the foreseeable future. If anything, I prefer to ask the existing users to perform a conscious migration today, than wait till things become really unusable and more users are forced to migrate their systems without realizing the risks. It's all nice to say that LibreSSL will be usable in the near future but that's just plain lying. We're between LibreSSL upstream that explicitly rejects any idea of interoperability with OpenSSL, and other upstreams that plain reject the idea of bending their software to work with LibreSSL. I'm sorry to say but in my opinion LibreSSL's team attitude is to blame in the first place here. If someone forks something, deliberately breaks compatibility and then tries everyone to use his work, what else would you expect to happen? -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, Dec 29, 2020 at 11:31:32PM +0100, Michał Górny wrote: > What I'm really missing in all the replies is a single reason why > LibreSSL would be better for anyone. Not 'it's an alternative', not > 'I don't trust' but a real proper, verifiable argument 'LibreSSL is > better in this regard'. I guess that is due the fact that you dismiss arguments that are valid reasons for others (incl. me) but apparently not sufficient for you, like my situation where 'It works on all my systems, and switching would mean work for me and at least a risk of downtimes'. I understand that if security of OpenSSL is much better than LibreSSL (I have also not seen 'proof' of this, just 'more users mean better security per se', so I guess I should switch from Gentoo to Ubuntu for my desktops and CentOS for my servers if I care about security), I should switch back, but for me, not having to touch working systems is a valid reason to keep the system around. Since I can't contribute the work needed to keep it around, I'll have to live with the consequences of whatever the devs decide. And I will. Just don't expect me to pretend like you are doing me a favour. ;-) Best, Marcel
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
We could clearly discuss forever, but since you refuse to engage with my constructive proposition and my ask for feedback there's no point, is there? It's super sad that you behave like that in Gentoo. Michał Górny wrote: > Choice for the sake of choice is meaningless. Far from it. > So far nobody has been able to find a strong argument for choosing > LibreSSL. There are strong arguments for using OpenSSL instead. That's like your opinion, man. :) > Maybe LibreSSL had promised a better taste in the beginning but today > 9 out of 10 consumers say OpenSSL tastes much better. It's usually harmful to optimize for popularity; smoking isn't a good idea even if everyone in school does it. > The only difference is that you don't have to pay > for it (but we do!), so you think that it's free. Please stop playing the victim and engage with my proposal instead. I'd appreciate feedback from everyone. Thanks a lot //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, 2020-12-29 at 22:41 +, Peter Stuge wrote: > Michał Górny wrote: > > > I would be happier if some other developers were able and willing > > > to > > > participate actively in the LibreSSL project. > > > > But why would they do that? What I'm really missing in all the > > replies > > is a single reason why LibreSSL would be better for anyone. > > Maybe because it is so well-known that monoculture is harmful per se, > which is why the commitment to choice in Gentoo is very valuable. How is that an argument for LibreSSL? If I create another fork of OpenSSL and replace LibreSSL with it, your argument still stands. > Further, LibreSSL comes out of the OpenBSD project, which has a good > reputation on code quality. I could buy that if it actually said anything about LibreSSL code quality. So far you're guessing that it might or might not, especially given it is forked from an apparently 'inferior quality' code. However, I do have serious doubts about LibreSSL quality given that: 1. Non-OpenBSD systems are not first class citizens, as you yourself pointed out. 2. The library is an intrusive replacement for OpenSSL. In the default setup, it is neither co-installable with OpenSSL, nor a drop-in replacement. 3. The upstream declares OpenSSL version constants pretty randomly, without actually matching OpenSSL API. 4. The upstream has actively tried to force people into using their product by tight coupling and forced incompatibility. 5. Apparently nobody is issuing CVEs for LibreSSL while the vulnerabilities clearly do happen. > > a real proper, verifiable argument 'LibreSSL is better in this > > regard'. > > Choice is about enabling people to decide for themselves. Choice for the sake of choice is meaningless. I can create 10 OpenSSL forks right now and tell people to choose between them. However, it is meaningless unless users are actually provided good and useful information on what particular choices represent. So far nobody has been able to find a strong argument for choosing LibreSSL. There are strong arguments for using OpenSSL instead. So what do users exactly gain from this choice? The thrill of adventure? The ability to discover that they've made a bad choice eventually and revert to OpenSSL? Let's say you have food product A. Then a new alternative B appears. Surely, some people will try it. But if it turns out to be bad, it will eventually unprofitable and disappear. Sure, a few people will complain that B is no longer there because they liked it better. But they wouldn't pay extra (much extra) to keep it. OpenSSL/LibreSSL is the same. Maybe LibreSSL had promised a better taste in the beginning but today 9 out of 10 consumers say OpenSSL tastes much better. The only difference is that you don't have to pay for it (but we do!), so you think that it's free. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
David Seifert wrote: > > Maybe because it is so well-known that monoculture is harmful per se, > > which is why the commitment to choice in Gentoo is very valuable. > > > > Further, LibreSSL comes out of the OpenBSD project, which has a good > > reputation on code quality. > > Like strong-arming 99% of the users of OpenSSH because they were > unwilling to port to the OpenSSL 1.1 API, fully well knowing that most > of the OpenSSH consuming world doesn't actually use libressl? How is > explicitly tying OpenSSH to libressl not a form of monoculture? Now we're properly off-topic :) but considering that OpenSSH is developed for OpenBSD and that openssh-portable is merely provided as a service to other systems it's easy to understand why OpenSSH (remember, part of OpenBSD) uses the libressl API for crypto, and why the -portable team is not so keen on maintaining patches for other crypto providers. Another example is systemd binding tightly to Linux. In both cases it's understandable, but also quite unfortunate; better portability would be better. > Case in point: Have you tried using the official libjpeg package instead > of libjpeg-turbo? Go ahead, give it a try. I'll take a look. I chose libjpeg-turbo for a project because it cross-compiled better. > "Monoculture"s are mostly a coincidence, not some sinister conspiracy. I don't claim conspiracy, I just say that it's healthy to avoid them. > Implementation-diversity-but-API-compatibility is mostly a > pipe dream, as libav, imagemagick, libjpeg have shown. I've been fortunate to have a different experience with other codebases. It's completely possible, but takes (extra!) effort, meaning you have to really want it. If there is some rivalry then it's also quite easy to sabotage your colleagues. //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, 2020-12-29 at 22:41 +, Peter Stuge wrote: > Michał Górny wrote: > > > I would be happier if some other developers were able and willing > > > to > > > participate actively in the LibreSSL project. > > > > But why would they do that? What I'm really missing in all the > > replies > > is a single reason why LibreSSL would be better for anyone. > > Maybe because it is so well-known that monoculture is harmful per se, > which is why the commitment to choice in Gentoo is very valuable. > > Further, LibreSSL comes out of the OpenBSD project, which has a good > reputation on code quality. Like strong-arming 99% of the users of OpenSSH because they were unwilling to port to the OpenSSL 1.1 API, fully well knowing that most of the OpenSSH consuming world doesn't actually use libressl? How is explicitly tying OpenSSH to libressl not a form of monoculture? If you want to provide an alternative, you have to subsume the API, not make it superficially compatible, only to find out that the you need to mask out a ton of stuff with macros. Case in point: Have you tried using the official libjpeg package instead of libjpeg-turbo? Go ahead, give it a try. "Monoculture"s are mostly a coincidence, not some sinister conspiracy. Implementation-diversity-but-API-compatibility is mostly a pipe dream, as libav, imagemagick, libjpeg have shown.
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Michał Górny wrote: > > I would be happier if some other developers were able and willing to > > participate actively in the LibreSSL project. > > But why would they do that? What I'm really missing in all the replies > is a single reason why LibreSSL would be better for anyone. Maybe because it is so well-known that monoculture is harmful per se, which is why the commitment to choice in Gentoo is very valuable. Further, LibreSSL comes out of the OpenBSD project, which has a good reputation on code quality. > a real proper, verifiable argument 'LibreSSL is better in this regard'. Choice is about enabling people to decide for themselves. Choice is /not/ about forcing people to formally prove utility to yourself. I acknowledge that what I suggest isn't immediately enabling libressl as a choice either, but it is at least far less destructive than masking and removal. //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Wed, 2020-12-30 at 01:00 +0300, Stefan Strogin wrote: > I would be happier if some other developers were able and willing to > participate > actively in the LibreSSL project. But if not, not. > Just make the transition as painless as possible. But why would they do that? What I'm really missing in all the replies is a single reason why LibreSSL would be better for anyone. Not 'it's an alternative', not 'I don't trust' but a real proper, verifiable argument 'LibreSSL is better in this regard'. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Matt Turner wrote: > > I think many mails in this thread suffer from some tunnel vision, expecting > > that a libressl ebuild in the tree must continue to work exactly like the > > openssl ebuild - I'm saying to stop that but do keep a libressl ebuild. To clarify, by "stop that" I mean "stop efforts to make libressl a drop-in replacement". > If they suffer from tunnel vision, it's because the intersection of > "people who care about libressl" and "people who have patches in > gentoo.git" is the empty set. Tunnel vision refered not to people but what a libressl ebuild delivers, which you seems to have turned into an ad hominem against me? Who will do actual work is a separate question, of course if noone wants to then nothing matters, but it seems that some people /do/ care about libressl; I suppose the 61 patches mgorny found were committed by someone. If you were somehow trying to belittle /me/ then it's certainly true that I'm not a Gentoo developer, but there are some patches by me in gentoo.git. > I think we all understand your points: libressl could be kept in-tree > and allow people to play with it. Unfortunately that requires much > more work than removing it, and I haven't seen evidence that you're > prepared to contribute to the required effort. > > I don't think you're going to convince a bunch of people with little > interest in libressl per se to continue allowing the extra burden > unless you do the work that's needed to keep it in-tree (e.g., to > allow it to be installed beside openssl). You seem to not understand my point at all. As I've written I (like others) argue against "continue allowing extra burden" and I've suggested and offered to help with one approach to keep a libressl ebuild in the tree. //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Hi, On 28/12/2020 11:56, Michał Górny wrote: > Hello, developers and Gentoo LibreSSL team. > > TL;DR: is there really a point in continuing the never-ending always- > regressing struggle towards supporting LibreSSL in Gentoo? > I don't agree. I have asked ~20 users who made any contributions (like bug reports or patches) recently, and almost all of them think that having a choice between OpenSSL and LibreSSL adds value to Gentoo. Some still trust LibreSSL more than OpenSSL because of its sins of the past. Although I can see that OpenSSL made a good progress in the latest several years. Anyway LibreSSL serves well to some number of users, and switching back to OpenSSL can be troublesome (think if you had dozens of servers running LibreSSL). LibreSSL support in Gentoo is not critical for me. But it doesn't take too much effort. I think the cost-benefit ratio is good enough for keeping it. Last but not least, the LibreSSL itself is well, alive and actively developed. People might want to use it. I see no good reasons not to support it, other than lack of time, will and effort. I really think that ability to choose (even between things that do not have great advantage over each other) - is a value in itself. > > The vast majority of software is not tested against LibreSSL. While > patches are usually trivial and we have people that submit them, > I find many of them short-sighted. Just look at [1]. Sure, it fixes > the build today but it disabled the feature for all foreseeable future. > How likely is it that somebody will submit another patch reenabling it > with a future LibreSSL version? The likelihood is greater than zero: https://github.com/lighttpd/lighttpd1.4/commit/57f450f1992fc4e28cf85969eeebccb240df4303 https://github.com/gentoo-mirror/gentoo/commit/c7792db235647a6441b315528997b40ba2beeaaa https://github.com/Yubico/yubico-piv-tool/commit/3bcd36bbdbbdc86d06cc53df7e3b7c30d12cd33e etc... That was why I disagree. But I'll acquiesce in the decision to remove LibreSSL, because the number of developers that actually work on LibreSSL support is about 1.5. And unfortunately I don't have much time and effort for Gentoo currently, because of the main job and other life (I hope it will change soon though). I would be happier if some other developers were able and willing to participate actively in the LibreSSL project. But if not, not. Just make the transition as painless as possible.
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, Dec 29, 2020 at 2:47 PM Peter Stuge wrote: > > Andreas K. Huettel wrote: > > > I agree completely that it's unreasonable for Gentoo (worse, 1 person!) > > > to continuosly patch the entire world for libressel. > > > > > > I'm asking to stop doing that, yet still enable the choice between > > > openssl and libressl where that is possible without patches, even > > > if that's only openntpd and one other package. > > > > a) The two cannot be installed concurrently. To fix that would require even > > more hacks. > > As we've discussed in another part of the thread, that's not really true. > Both can for sure be installed, just not in the same place and/or > with same names. > > > > -> all relevant ssl consumers on the user's system must be linked against > > the one selected > > Also not the case. Considering the two installed in different paths > with same names it's still easy for consumers to use one or the other > with -rpath at link time. > > > I do agree that the two are not always 1:1 replacements for each other. > If they are API incompatible somewhere then for sure not. > > I think many mails in this thread suffer from some tunnel vision, expecting > that a libressl ebuild in the tree must continue to work exactly like the > openssl ebuild - I'm saying to stop that but do keep a libressl ebuild. If they suffer from tunnel vision, it's because the intersection of "people who care about libressl" and "people who have patches in gentoo.git" is the empty set. I think we all understand your points: libressl could be kept in-tree and allow people to play with it. Unfortunately that requires much more work than removing it, and I haven't seen evidence that you're prepared to contribute to the required effort. I don't think you're going to convince a bunch of people with little interest in libressl per se to continue allowing the extra burden unless you do the work that's needed to keep it in-tree (e.g., to allow it to be installed beside openssl). They're not interested.
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
The bindist flags in openssl + openssh were for elliptic curve support, as people were concerned about patents. I'm almost certain this affects libressl just the same way, probably just noone ever bothered to care. The bindist flags should probably be reviewed and likely removed. According to Wikipedia [1] the last possibly relevant ECC patent is valid until 2020. So 2 more days. There shouldn't be any patent concerns about ECC any more. [1] https://en.wikipedia.org/wiki/ECC_patents -- Hanno Böck https://hboeck.de/ pgpa_2EgH5hwV.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Andreas K. Huettel wrote: > > I agree completely that it's unreasonable for Gentoo (worse, 1 person!) > > to continuosly patch the entire world for libressel. > > > > I'm asking to stop doing that, yet still enable the choice between > > openssl and libressl where that is possible without patches, even > > if that's only openntpd and one other package. > > a) The two cannot be installed concurrently. To fix that would require even > more hacks. As we've discussed in another part of the thread, that's not really true. Both can for sure be installed, just not in the same place and/or with same names. > -> all relevant ssl consumers on the user's system must be linked against > the one selected Also not the case. Considering the two installed in different paths with same names it's still easy for consumers to use one or the other with -rpath at link time. I do agree that the two are not always 1:1 replacements for each other. If they are API incompatible somewhere then for sure not. I think many mails in this thread suffer from some tunnel vision, expecting that a libressl ebuild in the tree must continue to work exactly like the openssl ebuild - I'm saying to stop that but do keep a libressl ebuild. > b) The libraries are not guaranteed to be binary compatible, so switching > implementation requires rebuilding consumers. We can only consider ABI compatibility if we have API compatibility, which might not even be a given. > c) If a single package that the user wants to install is not "fixed" for > one ssl library, it blocks that option for all packages. Please think of a libressl ebuild in a new way. > I guess if you can come up with a solution that > * provides secure usage of the libraries, > * provides choice to the user, and > * doesn't lead to unupgradeable systems or unresolvable dependencies > we'd all be happier. So far we haven't found one. Right! I think letting a libressl ebuild install only libtls could be a good start, because it provides a stable situation, without risking conflicts. Would you agree? Thanks //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, Dec 29, 2020 at 01:24:33PM +0100, Michał Górny wrote: > As noted in another fork of this thread, libtls is now provided > by dev-libs/libretls which works against OpenSSL. The latest version of libressl also supports linking libtls statically against libssl and libcrypto, allowing it to be used alongside openssl while still using libressl guts. Of course, then you'd end up with basically two ssl implementations loaded, so dunno it's very efficient, but just to point it out :).
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, Dec 29, 2020 at 02:57:12PM +0100, m1027 wrote: > > > On 29 Dec 2020, at 09:13, Marcel Schilling > > > wrote: > > > > > > I just want to comment that I switched to LibreSSL on several > > > Gentoo systems years ago and never had any major issues. I run > > > both desktop and server systems with LibreSSL, based on X and > > > Wayland. The only issues I ran into is a slight lag of the > > > overlay behind the main tree so once in a while I had to mask a > > > new version of some package for a week or so. > > Let me just come back on the different views here: > > @marcel: Exactly the same here. Smoothly running libressl on dozens > of systems here, from embedded to ryzen servers, even on Gnome > desktops. At least from the libressl *user's* perspective. > > sam: > > > TL;DR: [...libressl patches are...] just crippling functionality. > > @sam: From the perspective of libressl maintainers I have had a hard > time reading this thread ;-) to learn that even security is supposed > to be an issue with libressl today!? Aren't these crippling patches > sometimes even helpful (see some apache patches) to crop unreliable > extra features? I might be wrong here. Actually I'd prefer something > 'boring' and stable on ssl over new features... > > Well, I cannot judge on the security issues in depth. From a short > internet scan I don't see recent libressl issues but e.g. this one > on openssl, https://www.openssl.org/news/vulnerabilities.html, only > three weeks ago. That particular vulnerability (CVE-2020-1971) affects both libressl and openssl, and Gentoo has bugs for both. https://bugs.gentoo.org/759079 https://bugs.gentoo.org/759175 The openssl bug has been fixed, but the libressl bug remains open, despite both being opened within two days of each (and now existing for several weeks). signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Am Dienstag, 29. Dezember 2020, 13:29:35 EET schrieb Peter Stuge: > I agree completely that it's unreasonable for Gentoo (worse, 1 person!) > to continuosly patch the entire world for libressel. > > I'm asking to stop doing that, yet still enable the choice between > openssl and libressl where that is possible without patches, even > if that's only openntpd and one other package. a) The two cannot be installed concurrently. To fix that would require even more hacks. -> all relevant ssl consumers on the user's system must be linked against the one selected b) The libraries are not guaranteed to be binary compatible, so switching implementation requires rebuilding consumers. Especially since this is a security-sensitive package. -> all relevant ssl consumers on the user's system must be *built* against the one selected Which leads us to c) If a single package that the user wants to install is not "fixed" for one ssl library, it blocks that option for all packages. -> horrible (but real and justified) emerge blockers and general hilarity ensue I guess if you can come up with a solution that * provides secure usage of the libraries, * provides choice to the user, and * doesn't lead to unupgradeable systems or unresolvable dependencies we'd all be happier. So far we haven't found one. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice)
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On 12/29/20 7:15 PM, Michał Górny wrote: I'm not sure if you meant it but it reads as if you were talking about removing the package. This is incorrect. You need to disable the USE flag and then --changed-use (or --newuse) rebuild everything with the flag. If the depgraph is clean, emerge should happily trigger the rebuild along with automatic replacement of dev-libs/libressl with dev-libs/openssl. You're right, the USE flags have to be adapted - forget that to mention, sry. -- Toralf PGP 23217DA7 9B888F45 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On 12/29/20 7:10 PM, m1027 wrote: toralf: On 12/29/20 2:57 PM, m1027 wrote: - removing libressl, installing openssl, maybe wget then, followed by the rest? remove is sufficient b/c emerge then immediately advices a @preserved-rebuild - at least that's the way it works here at the tinderbox (in the opposite direction FWIW) I gave it a shot and it did not work that way here. After uninstalling libressl and removing all according USE flags, @preserved-rebuild always tried to pull in libressl again. Maybe emerge -1 openssl, then emerge -auDUN @preserved-rebuild --nodeps helps. Hhm, for OpenSSL->LibreSSL this works since years to autaomtically setup a new tinderbox image: https://github.com/toralf/tinderbox/blob/master/bin/setup_img.sh#L494 but I never tried the other way around. -- Toralf PGP 23217DA7 9B888F45 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, 2020-12-29 at 16:12 +0100, Toralf Förster wrote: > On 12/29/20 2:57 PM, m1027 wrote: > > - removing libressl, installing openssl, maybe wget then, followed > > by the rest? > remove is sufficient b/c emerge then immediately advices a > @preserved-rebuild - at least that's the way it works here at the > tinderbox (in the opposite direction FWIW) > I'm not sure if you meant it but it reads as if you were talking about removing the package. This is incorrect. You need to disable the USE flag and then --changed-use (or --newuse) rebuild everything with the flag. If the depgraph is clean, emerge should happily trigger the rebuild along with automatic replacement of dev-libs/libressl with dev-libs/openssl. However, it's a good idea to run the same command with --fetchonly first, to make sure that all distfiles are in place, in case wget got broken in the process. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
toralf: > On 12/29/20 2:57 PM, m1027 wrote: > > - removing libressl, installing openssl, maybe wget then, followed > >by the rest? > > remove is sufficient b/c emerge then immediately advices a > @preserved-rebuild - at least that's the way it works here at the > tinderbox (in the opposite direction FWIW) I gave it a shot and it did not work that way here. After uninstalling libressl and removing all according USE flags, @preserved-rebuild always tried to pull in libressl again. Maybe emerge -1 openssl, then emerge -auDUN @preserved-rebuild --nodeps helps.
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On 12/29/20 2:57 PM, m1027 wrote: - removing libressl, installing openssl, maybe wget then, followed by the rest? remove is sufficient b/c emerge then immediately advices a @preserved-rebuild - at least that's the way it works here at the tinderbox (in the opposite direction FWIW) -- Toralf PGP 23217DA7 9B888F45 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, 2020-12-29 at 14:57 +0100, m1027 wrote: > > > On 29 Dec 2020, at 09:13, Marcel Schilling > > > wrote: > > > > > > I just want to comment that I switched to LibreSSL on several > > > Gentoo systems years ago and never had any major issues. I run > > > both desktop and server systems with LibreSSL, based on X and > > > Wayland. The only issues I ran into is a slight lag of the > > > overlay behind the main tree so once in a while I had to mask a > > > new version of some package for a week or so. > > Let me just come back on the different views here: > > @marcel: Exactly the same here. Smoothly running libressl on dozens > of systems here, from embedded to ryzen servers, even on Gnome > desktops. At least from the libressl *user's* perspective. > > sam: > > > TL;DR: [...libressl patches are...] just crippling functionality. > > @sam: From the perspective of libressl maintainers I have had a hard > time reading this thread ;-) to learn that even security is supposed > to be an issue with libressl today!? Aren't these crippling patches > sometimes even helpful (see some apache patches) to crop unreliable > extra features? I might be wrong here. Actually I'd prefer something > 'boring' and stable on ssl over new features... > > Well, I cannot judge on the security issues in depth. From a short > internet scan I don't see recent libressl issues but e.g. this one > on openssl, https://www.openssl.org/news/vulnerabilities.html, only > three weeks ago. > > Anyway, my personal conclusion on security: > > I've once switched to libressl because of the heartbleed issue. If > security is better with openssl these days, I'd of course switch > back. I can't say anything for sure but it is pretty clear that since Heartbleed the level of auditing OpenSSL is receiving is much greater. I honestly doubt that with its comparatively little user base LibreSSL gets the same level of attention. I don't really have the time or motivation to try to look for LibreSSL security issues. But if there's no CVE for such a core package for two years, it either means that it's really good, that it's practically dead or that nobody is actually releasing CVEs for it. > It might be worth having some warm explanations on the > motivation in eselect NEWS, to help people out of the initial state > of shock. Of course a news item will be released once we determine the proper course of action. > > > > So from a pure user perspective, thing change would mean a risky > > > update > > > to systems running stable for years with no gain whatsoever. > > Coming back on the technical way to switch back to openssl: > > Thanks to Gentoo, isn't the switch back more or less something > predictable like > > - removing libressl USE / CURL flags > > - download everything before compiling (emerge -f ...) > > - removing libressl, installing openssl, maybe wget then, followed > by the rest? > > It plead for something that actually *works* as many systems will > need that change here. > We are currently waiting for test results. We don't want to guess without testing for sure. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
> TL;DR: is there really a point in continuing the never-ending always- > regressing struggle towards supporting LibreSSL in Gentoo? > > I would like to discuss the possibility of discontinuing LibreSSL > support in Gentoo in favor of sticking with OpenSSL. From a team member and initial "believer", yes please. Libressl turns out to be more pain than gain. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
> > On 29 Dec 2020, at 09:13, Marcel Schilling > > wrote: > > > > I just want to comment that I switched to LibreSSL on several > > Gentoo systems years ago and never had any major issues. I run > > both desktop and server systems with LibreSSL, based on X and > > Wayland. The only issues I ran into is a slight lag of the > > overlay behind the main tree so once in a while I had to mask a > > new version of some package for a week or so. Let me just come back on the different views here: @marcel: Exactly the same here. Smoothly running libressl on dozens of systems here, from embedded to ryzen servers, even on Gnome desktops. At least from the libressl *user's* perspective. sam: > TL;DR: [...libressl patches are...] just crippling functionality. @sam: From the perspective of libressl maintainers I have had a hard time reading this thread ;-) to learn that even security is supposed to be an issue with libressl today!? Aren't these crippling patches sometimes even helpful (see some apache patches) to crop unreliable extra features? I might be wrong here. Actually I'd prefer something 'boring' and stable on ssl over new features... Well, I cannot judge on the security issues in depth. From a short internet scan I don't see recent libressl issues but e.g. this one on openssl, https://www.openssl.org/news/vulnerabilities.html, only three weeks ago. Anyway, my personal conclusion on security: I've once switched to libressl because of the heartbleed issue. If security is better with openssl these days, I'd of course switch back. It might be worth having some warm explanations on the motivation in eselect NEWS, to help people out of the initial state of shock. > > So from a pure user perspective, thing change would mean a risky update > > to systems running stable for years with no gain whatsoever. Coming back on the technical way to switch back to openssl: Thanks to Gentoo, isn't the switch back more or less something predictable like - removing libressl USE / CURL flags - download everything before compiling (emerge -f ...) - removing libressl, installing openssl, maybe wget then, followed by the rest? It plead for something that actually *works* as many systems will need that change here. Thanks
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
David Seifert wrote: > > > I mean, you have to explicitly support the choice in ebuilds, > > > and this means making things even harder for newcomers. > > > > pkg-config/pkgconf and .pc files can help with this part, taking care > > of all abstraction if/when downstream uses a libressl.pc. > > As we have learned from the ncurses[tinfo] debacle, 80% of build systems > don't use the .pc files, and just guess "-lssl" flags and a bunch of > include dirs. Did the debacle actually involve -lssl ? I guess that it depends on the particular library - with an old library such as ncurses I can imagine that .pc is much less established, and I have indeed seen pretty ugly OpenSSL detection in configure.acs, they could still remain, and would then simply never catch libressl, I think that would be fine. > > > The big problem is that (unless I'm mistaken) we won't be able to > > > load LibreSSL and OpenSSL to the same executable. > > > > I'd suggest investigating whether symbol versioning could help with > > this, or if the only way forward would indeed be to require some symbol > > mangling/rewriting. > > While this sounds like a theoretical solution, it isn't tractable because > 1. We're inventing our own ABI that is incompatible with everyone else's ABI for a given library doesn't neccessarily matter beyond the individual system, does it? For something like reproducible builds of course it does. > 2. We'd have to maintain a huge swamp of downstream patches Nono, no patches of course, it would have to be automatic, if only for the local system. > 3. ABI can still break even with perfect symbol versioning Oh? This may be unrelated, but can you tell more or provide a pointer? Thanks! //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
вт, 29 дек. 2020 г. в 13:33, David Seifert :
>
> On Tue, 2020-12-29 at 13:21 +, Peter Stuge wrote:
> > Michał Górny wrote:
> > > > 2. Install them into different prefixes (eg /usr/lib/openssl +
> > > > /usr/lib/libressl and have the linker link to a specific version,
> > > > /usr/include/{openssl,libressl} too).
> > >
> > > For the record, this is something I've been wondering about for a
> > > long
> > > time. However, there are two problems with that: a small one
> > > and a huge one.
> > >
> > > The small problem is that this requires a lot of additional
> > > downstream
> > > work. I mean, you have to explicitly support the choice in ebuilds,
> > > and this means making things even harder for newcomers.
> >
> > pkg-config/pkgconf and .pc files can help with this part, taking care
> > of all abstraction if/when downstream uses a libressl.pc.
>
> As we have learned from the ncurses[tinfo] debacle, 80% of build systems
> don't use the .pc files, and just guess "-lssl" flags and a bunch of
> include dirs. Hence, this boils down to patching a mountain of build
> systems again, which while being the ultimately correct way, is a pipe
> dream.
If it's the ultimately correct way, such patches can be sent upstream,
regardless of whether libressl stays.
>
> > > The big problem is that (unless I'm mistaken) we won't be able to
> > > load
> > > LibreSSL and OpenSSL to the same executable. So we'd actually have
> > > to
> > > enforce that the whole link chain links to the same SSL provider,
> > > and effectively land pretty close to where we are now.
> >
> > I'd suggest investigating whether symbol versioning could help with
> > this,
> > or if the only way forward would indeed be to require some symbol
> > mangling/rewriting.
>
> While this sounds like a theoretical solution, it isn't tractable
> because
> 1. We're inventing our own ABI that is incompatible with everyone else's
> 2. We'd have to maintain a huge swamp of downstream patches
> 3. ABI can still break even with perfect symbol versioning
>
>
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, 2020-12-29 at 13:21 +, Peter Stuge wrote:
> Michał Górny wrote:
> > > 2. Install them into different prefixes (eg /usr/lib/openssl +
> > > /usr/lib/libressl and have the linker link to a specific version,
> > > /usr/include/{openssl,libressl} too).
> >
> > For the record, this is something I've been wondering about for a
> > long
> > time. However, there are two problems with that: a small one
> > and a huge one.
> >
> > The small problem is that this requires a lot of additional
> > downstream
> > work. I mean, you have to explicitly support the choice in ebuilds,
> > and this means making things even harder for newcomers.
>
> pkg-config/pkgconf and .pc files can help with this part, taking care
> of all abstraction if/when downstream uses a libressl.pc.
As we have learned from the ncurses[tinfo] debacle, 80% of build systems
don't use the .pc files, and just guess "-lssl" flags and a bunch of
include dirs. Hence, this boils down to patching a mountain of build
systems again, which while being the ultimately correct way, is a pipe
dream.
> > The big problem is that (unless I'm mistaken) we won't be able to
> > load
> > LibreSSL and OpenSSL to the same executable. So we'd actually have
> > to
> > enforce that the whole link chain links to the same SSL provider,
> > and effectively land pretty close to where we are now.
>
> I'd suggest investigating whether symbol versioning could help with
> this,
> or if the only way forward would indeed be to require some symbol
> mangling/rewriting.
While this sounds like a theoretical solution, it isn't tractable
because
1. We're inventing our own ABI that is incompatible with everyone else's
2. We'd have to maintain a huge swamp of downstream patches
3. ABI can still break even with perfect symbol versioning
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Michał Górny wrote:
> > 2. Install them into different prefixes (eg /usr/lib/openssl +
> > /usr/lib/libressl and have the linker link to a specific version,
> > /usr/include/{openssl,libressl} too).
>
> For the record, this is something I've been wondering about for a long
> time. However, there are two problems with that: a small one
> and a huge one.
>
> The small problem is that this requires a lot of additional downstream
> work. I mean, you have to explicitly support the choice in ebuilds,
> and this means making things even harder for newcomers.
pkg-config/pkgconf and .pc files can help with this part, taking care
of all abstraction if/when downstream uses a libressl.pc.
> The big problem is that (unless I'm mistaken) we won't be able to load
> LibreSSL and OpenSSL to the same executable. So we'd actually have to
> enforce that the whole link chain links to the same SSL provider,
> and effectively land pretty close to where we are now.
I'd suggest investigating whether symbol versioning could help with this,
or if the only way forward would indeed be to require some symbol
mangling/rewriting.
//Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, 2020-12-29 at 14:39 +0200, Jaco Kroon wrote:
> 2. Install them into different prefixes (eg /usr/lib/openssl +
> /usr/lib/libressl and have the linker link to a specific version,
> /usr/include/{openssl,libressl} too).
For the record, this is something I've been wondering about for a long
time. However, there are two problems with that: a small one
and a huge one.
The small problem is that this requires a lot of additional downstream
work. I mean, you have to explicitly support the choice in ebuilds,
and this means making things even harder for newcomers.
The big problem is that (unless I'm mistaken) we won't be able to load
LibreSSL and OpenSSL to the same executable. So we'd actually have to
enforce that the whole link chain links to the same SSL provider,
and effectively land pretty close to where we are now.
--
Best regards,
Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Michał Górny wrote:
> > net-misc/openntpd
>
> I've just tested it and it builds fine against dev-libs/libretls.
I hope you're not planning to suggest that dev-libs/libretls should
be the only libtls on Gentoo, since that would be an arbitrary and
artificial limitation - the very opposite of choice. I'm strongly
against that.
Jaco Kroon wrote:
> > I'm asking to stop doing that, yet still enable the choice between
> > openssl and libressl where that is possible without patches, even
> > if that's only openntpd and one other package.
>
> Are you willing to put in the work to allow installing openssl and
> libressl concurrently on the same system?
I'm willing to help. I know that it's one or the other. And I have
experience with distributions making arbitrary decisions about libraries,
and I think I have an idea about the challenges and possibilities.
> The only real solution then to make libressl viable is to make it
> co-exist with openssl reliably.
Ack.
> Of course there are various strategies (or combination of), to mention
> but a few:
>
> 1. Use a virtual/??? (but since the APIs aren't compatible despite the
> libressl promise thereto ...)
> 2. Install them into different prefixes (eg /usr/lib/openssl +
> /usr/lib/libressl and have the linker link to a specific version,
> /usr/include/{openssl,libressl} too).
> 3. Make ssl USE flag another single-choice USE_EXPAND, posibly by way
> of openssl.eclass.
These are all interesting and I think worth exploring! But also
non-trivial, so maybe better saved for later?
What do you think about my suggestion in a previous email to have the
libressl ebuild install only libtls .so and .a files built from static
libs/objects, so that there are no conflicting shared objects?
I can certainly help accomplish that if there is interest.
> would be in willing and in support of updating the packages I maintain
> to assist with libressl support if the eco system can be improved.
Cool! I really appreciate your openness. I'm asking essentially to
keep options open, so that the ecosystem can be improved step by step.
Thanks
//Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, 2020-12-29 at 13:41 +0100, Toralf Förster wrote: > On 12/29/20 1:23 PM, Michał Górny wrote: > > 2. Stuff that builds just fine but fails at runtime in > > unpredictable > > ways (e.g. Tor mentioned today). > > FWIW that's exactly what I do suffer from at my Tor relays. > > Beside that a naive question: Wouldn't it be siufficient to just > have/keep the libressl overlay/repo? > So whoever wants to use LibreSSL in future just configure its portage > to > use that? > I don't have a problem with that. What I do have a problem with is: 1. People submitting bad patches upstream (but I guess that's inevitable). 2. Maintaining downstream patches forever. 3. Being blocked by libressl patches no longer applying. I wouldn't mind keeping LibreSSL if it was possible to actually maintain it without causing these problems. But I don't think it's possible to do that. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Michał Górny wrote: > 1. Stuff that does not build against LibreSSL. > 2. Stuff that builds just fine but fails at runtime in unpredictable > ways (e.g. Tor mentioned today). > 3. Stuff that builds and works 'fine' but ends up being crippled (e.g. > doesn't support new algorithms). > > The first one is somewhat easy to test (e.g. via tinderbox). The other > two are very hard. Nod. > > > Actually, I see that someone has apparently forked libtls into > > > libretls (the irony!) that works against OpenSSL [1]. > > > > To me, that proves value in the libtls API and in keeping libressl in > > the tree in some capacity, even if not as an alternative to openssl. > > > > Maybe with a USE flag which makes it install only libtls (built from > > libressl static libs), which could be one provider for a > > virtual/libtls. > > I don't see why we would put an effort into that. In my very next sentence (not quoted in your reply) I wrote explicitly that I do /not/ ask anyone to do so, but ask that you don't hinder it by masking libressl and also don't remove existing work potentially supporting such efforts, ie. the libressl ebuild. > I've just packaged dev-libs/libretls Thanks! That seems useful. > Trying to get the same result from libressl is just repeating the work. Maybe for you, and I'm saying that you should be able to make that choice for your systems, but also that you should not hinder others from making another choice, where that's possible and as I wrote without needing Gentoo to patch the world. Thanks a lot //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On 12/29/20 1:23 PM, Michał Górny wrote: 2. Stuff that builds just fine but fails at runtime in unpredictable ways (e.g. Tor mentioned today). FWIW that's exactly what I do suffer from at my Tor relays. Beside that a naive question: Wouldn't it be siufficient to just have/keep the libressl overlay/repo? So whoever wants to use LibreSSL in future just configure its portage to use that? -- Toralf PGP 23217DA7 9B888F45 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Hi Peter,
On 2020/12/29 13:29, Peter Stuge wrote:
> Michał Górny wrote:
>>> I'm sure that there are numerous cases where libressl doesn't work,
>>> but that's no reason to dismiss cases where it *does*.
>> Are you asking people to put an effort into maintaining something that
>> can't be practically installed?
> No, I'm rather asking to change the level of commitment.
>
> I agree completely that it's unreasonable for Gentoo (worse, 1 person!)
> to continuosly patch the entire world for libressel.
>
> I'm asking to stop doing that, yet still enable the choice between
> openssl and libressl where that is possible without patches, even
> if that's only openntpd and one other package.
Are you willing to put in the work to allow installing openssl and
libressl concurrently on the same system?
And I raise this, because as others have insinuated, currently it's one
or the other, they can't co-exist, and there are a great many number of
packages that doesn't work with libressl. The only real solution then
to make libressl viable is to make it co-exist with openssl reliably.
Of course there are various strategies (or combination of), to mention
but a few:
1. Use a virtual/??? (but since the APIs aren't compatible despite the
libressl promise thereto ...)
2. Install them into different prefixes (eg /usr/lib/openssl +
/usr/lib/libressl and have the linker link to a specific version,
/usr/include/{openssl,libressl} too).
3. Make ssl USE flag another single-choice USE_EXPAND, posibly by way
of openssl.eclass.
My personal support currently goes towards at the very least masking
libressl, but removal unless someone is going to put in the effort
towards the above. Happy to help with patching on my own packages, but
without concurrent install of libre+openssl it's a massive workload to
test for me, so not happy with current state either.
+1 for removal given current state, but would be in willing and in
support of updating the packages I maintain to assist with libressl
support if the eco system can be improved.
Kind Regards,
Jaco
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, 2020-12-29 at 06:33 +0100, David Haller wrote: > Hello, > > On Mon, 28 Dec 2020, Michal Górny wrote: > > The only problem that I can think of are packages that depend > > on libressl specifically and do not support openssl. I don't think > > we > > have anything like that but I'll double check. > > A naive check finds these: > > Depends unconditionally on dev-libs/libressl: > app-crypt/acme-client Furthermore, it seems to be specifically relying on libressl internals (i.e. contents of opaque structures). Given that it doesn't build with gcc-10 and there's a lot of ACME clients around, I suppose we can last rite it. > Depends conditionally on only dev-libs/libressl (no openssl > alternative): > net-misc/s6-networking This dependency has been removed yesterday. > net-misc/openntpd I've just tested it and it builds fine against dev-libs/libretls. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Mon, 2020-12-28 at 21:42 +0100, Toralf Förster wrote: > On 12/28/20 8:55 PM, Michał Górny wrote: > > I might be wrong but I think the update should proceed cleanly with > > --changed-use/--newuse. > > Maybe it is worth to tell people within the news item to run sth like > > emerge --fetchonly dev-libs/openssl net-misc/openssh net-misc/wget > > before (to have at least the wget sources at disk before it becomes > temporary broken during @preserved-rebuild) ? > > IIRC I needed it to switch from OpenSSL to LIbreSSL at my server and > desktop (and coded it therefore into the tinderbox script too). Thanks, that's a very good suggestion. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Mon, 2020-12-28 at 23:26 +0100, m1027 wrote: > I've been kindly asked by a gentoo dev to send my two pence in here: > > peter: > > > Michał Górny wrote: > > > > > LibreSSL users, does LibreSSL today have any benefit over > > > OpenSSL? > > > > Yes, at least two: > > > > [...] > > > > B. It brings its own TLS API, a unique feature which by itself > > warrants > > the package. > > Yeah, since openssl and libressl cannot be installed at the same > time, I wonder what will be the future of libtls? To recall, it is > a "a new TLS library, designed to make it easier to write foolproof > applications" (see libressl.org). I've been using it for some time. > It's great, and it is part of libressl. As noted in another fork of this thread, libtls is now provided by dev-libs/libretls which works against OpenSSL. > Another thing: Besides libressl there are boringssl and others. Even > if still not the case (?), having virtual alternatives should in > theory help keeping polished interfaces. If for whatever reason this > not the case in practise, I believe dropping the alternatives should > be worse. I don't think these alternatives were ever meant to be used system- wide. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, 2020-12-29 at 11:29 +, Peter Stuge wrote: > Michał Górny wrote: > > > I'm sure that there are numerous cases where libressl doesn't > > > work, > > > but that's no reason to dismiss cases where it *does*. > > > > Are you asking people to put an effort into maintaining something > > that > > can't be practically installed? > > No, I'm rather asking to change the level of commitment. > > I agree completely that it's unreasonable for Gentoo (worse, 1 > person!) > to continuosly patch the entire world for libressel. > > I'm asking to stop doing that, yet still enable the choice between > openssl and libressl where that is possible without patches, even > if that's only openntpd and one other package. > > The method for that choice could of course depend on the number of > packages where it applies. I'm pretty sure that soon enough one of Portage/Python dependencies is going to become a blocker for everything. > > > > > Did anyone gather actual numbers? > > > > $ find -name '*libressl*.patch' | grep -v dev-libs/libressl | wc -l > > 61 > > I'm more interested in the number of packages which can use either > library without patches (like openntpd?). This may be tricky to find > out. :\ It's never that simple. Roughly speaking, there are 3 levels of incompatibility with LibreSSL: 1. Stuff that does not build against LibreSSL. 2. Stuff that builds just fine but fails at runtime in unpredictable ways (e.g. Tor mentioned today). 3. Stuff that builds and works 'fine' but ends up being crippled (e.g. doesn't support new algorithms). The first one is somewhat easy to test (e.g. via tinderbox). The other two are very hard. > > > > > > Actually, I see that someone has apparently forked libtls into > > libretls > > (the irony!) that works against OpenSSL [1]. > > To me, that proves value in the libtls API and in keeping libressl in > the tree in some capacity, even if not as an alternative to openssl. > > Maybe with a USE flag which makes it install only libtls (built from > libressl static libs), which could be one provider for a > virtual/libtls. I don't see why we would put an effort into that. I've just packaged dev-libs/libretls, and the maintenance effort in it seems really minimal. Trying to get the same result from libressl is just repeating the work. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
28.12.2020 11:56, Michał Górny пишет: I would like to propose that we stop patching packages, discontinue support for it and last rite it. I second this.
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
I agree with the proposal to sunset LibreSSL. Supporting it benefits very few users due to how non-universal the support of this option is. I see it as entirely sensible choice on apps' upstreams part to not collaborate on libressl support, motivation being focusing on more typical user setups. But I have one loosely related question. About USE=bindist of openssl & openssh. My impression is that when you spin up a new Gentoo setup from stage3, very early on you are typically forced by situations to switch off USE=bindist for openssl and openssh. I conclude that one can't redistribute more elaborate system images and binpkgs because of this. However there's no `bindist` flag and therefore no such situation with libressl package. I never did good research of why this is so, so I am still wondering: what does that mean in practice? Does this mean libressl has some advantage for binary redistributability of elaborate system images and binary packages? signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Michał Górny wrote: > > I'm sure that there are numerous cases where libressl doesn't work, > > but that's no reason to dismiss cases where it *does*. > > Are you asking people to put an effort into maintaining something that > can't be practically installed? No, I'm rather asking to change the level of commitment. I agree completely that it's unreasonable for Gentoo (worse, 1 person!) to continuosly patch the entire world for libressel. I'm asking to stop doing that, yet still enable the choice between openssl and libressl where that is possible without patches, even if that's only openntpd and one other package. The method for that choice could of course depend on the number of packages where it applies. > A side effect of this approach is that users will be tricked into using > LibreSSL, only to discover that they eventually have to transition > their systems back. I believe I'm asking for the opposite. I think it's fine to say that libressl has to be a deliberate choice rather than a default. > > Did anyone gather actual numbers? > > $ find -name '*libressl*.patch' | grep -v dev-libs/libressl | wc -l > 61 I'm more interested in the number of packages which can use either library without patches (like openntpd?). This may be tricky to find out. :\ > > > > B. It brings its own TLS API, a unique feature which by itself > > > > warrants the package. > > > > > > ...which by itself has no future > > > > That's arrogant and silly coming from anywhere but upstream. > > > > You can argue that you will never use the API in your TLS programs, > > but even then that says really nothing about the API provider itself. > > That's my opinion and I have a right to have it without being insulted. You absolutely have a right to your opinion but you stated it as fact, that made me react so strongly. > I don't dispute whether it's good. I dispute whether tightly binding > it to a problematic LibreSSL is a good idea. I agree with this, but only in cases where libressl is indeed problematic. I can think of systems where it isn't, there the choice is a good thing. > Actually, I see that someone has apparently forked libtls into libretls > (the irony!) that works against OpenSSL [1]. To me, that proves value in the libtls API and in keeping libressl in the tree in some capacity, even if not as an alternative to openssl. Maybe with a USE flag which makes it install only libtls (built from libressl static libs), which could be one provider for a virtual/libtls. Note: I'm not at all expecting anyone to do such work for me, I just don't want it to become impossible (libressl mask) or any existing effort supporting something like the above to be sunset. Does that make sense? Thanks! //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On December 29, 2020 4:39:06 AM EST, "Michał Górny" wrote: >On Mon, 2020-12-28 at 23:18 +, Peter Stuge wrote: >> Michał Górny wrote: >> > > A. It is a distinct implementation with probably /quite some/ >> > > stable >> > > compatibility, meaning that it will work perfectly fine as an >> > > alternative in many cases. >> > >> > Except that it doesn't, as has been proven numerous times. >> >> I'm sure that there are numerous cases where libressl doesn't work, >> but that's no reason to dismiss cases where it *does*. > >Are you asking people to put an effort into maintaining something that >can't be practically installed? 'I don't use a single Qt application >(yet!), so I demand you support LibreSSL for me!' > I don't see Peter demanding anything here. He has an opinion as a user and he has offered it. Just as others have offered theirs. >A side effect of this approach is that users will be tricked into using >LibreSSL, only to discover that they eventually have to transition >their systems back. We have been there with LibAV. However, unlike >LibAV, transition between SSL providers is non-trivial. > No one is tricking anyone into using LibreSSL. >> Did anyone gather actual numbers? > >$ find -name '*libressl*.patch' | grep -v dev-libs/libressl | wc -l >61 > >That's just the tip of the iceberg. Nobody's going to be able to even >guess how many upstream have accepted *bad* patches. How many packages >are forcing obsolete algorithms because someone added '!libressl' >conditions because LibreSSL keeps pretending to be a newer OpenSSL >version without actually implementing its API. > That's quite an assumption to assume all of these patches are "bad." >> > > B. It brings its own TLS API, a unique feature which by itself >> > > warrants the package. >> > >> > ...which by itself has no future >> >> That's arrogant and silly coming from anywhere but upstream. >> >> You can argue that you will never use the API in your TLS programs, >> but even then that says really nothing about the API provider itself. > >That's my opinion and I have a right to have it without being insulted. > Yes, you do. Just as others have a right to theirs without being spoken to as you have done so here. It is clear you have a problem with the LibreSSL implementation, but portraying that as a user being ignorant, demanding, or anythimg else is uncalled for to get your point across. Quit saying people are insulting you when you have clearly done so in the very same email response. >I don't dispute whether it's good. I dispute whether tightly binding >it to a problematic LibreSSL is a good idea. Sure, this means that >some people will be forced to use LibreSSL because of libtls. > >But in practice, this means that any upstream starting to use libtls >does a huge disservice to their users by preventing them from using >their preferred SSL provider. So in the end, you either don't use >libtls or your users are in pain. > >Actually, I see that someone has apparently forked libtls into libretls >(the irony!) that works against OpenSSL [1]. > >[1] https://git.causal.agency/libretls/about/ Anyway, +1 for LibreSSL removal. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Mon, 2020-12-28 at 23:18 +, Peter Stuge wrote: > Michał Górny wrote: > > > A. It is a distinct implementation with probably /quite some/ > > > stable > > > compatibility, meaning that it will work perfectly fine as an > > > alternative in many cases. > > > > Except that it doesn't, as has been proven numerous times. > > I'm sure that there are numerous cases where libressl doesn't work, > but that's no reason to dismiss cases where it *does*. Are you asking people to put an effort into maintaining something that can't be practically installed? 'I don't use a single Qt application (yet!), so I demand you support LibreSSL for me!' A side effect of this approach is that users will be tricked into using LibreSSL, only to discover that they eventually have to transition their systems back. We have been there with LibAV. However, unlike LibAV, transition between SSL providers is non-trivial. > Did anyone gather actual numbers? $ find -name '*libressl*.patch' | grep -v dev-libs/libressl | wc -l 61 That's just the tip of the iceberg. Nobody's going to be able to even guess how many upstream have accepted *bad* patches. How many packages are forcing obsolete algorithms because someone added '!libressl' conditions because LibreSSL keeps pretending to be a newer OpenSSL version without actually implementing its API. > > > B. It brings its own TLS API, a unique feature which by itself > > > warrants the package. > > > > ...which by itself has no future > > That's arrogant and silly coming from anywhere but upstream. > > You can argue that you will never use the API in your TLS programs, > but even then that says really nothing about the API provider itself. That's my opinion and I have a right to have it without being insulted. I don't dispute whether it's good. I dispute whether tightly binding it to a problematic LibreSSL is a good idea. Sure, this means that some people will be forced to use LibreSSL because of libtls. But in practice, this means that any upstream starting to use libtls does a huge disservice to their users by preventing them from using their preferred SSL provider. So in the end, you either don't use libtls or your users are in pain. Actually, I see that someone has apparently forked libtls into libretls (the irony!) that works against OpenSSL [1]. [1] https://git.causal.agency/libretls/about/ -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
> On 28 Dec 2020, at 10:02, Hanno Böck wrote: > > If it has any weight: > I think I was the first person to build Gentoo with LibreSSL. I support > this. > I’m pleased to have yours and blueness’ input. Really, I think going is probably best. Just make it clear it can come back with some new backing, if that ever happens. Thinking about it some more, we recently had QtNetwork users without security patches for a few weeks because (and this is not his fault) there’s only a bus factor of 1 for updating compatibility on every point release of Qt. I’m also unconvinced that if we suddenly lost LibreSSL compatibility in some @system or otherwise popular package we could restore functionality in any reasonable timeframe. Bit sad to be here, but here we are. > I believe pretty much everything that LibreSSL originally was > (consistent codingstyle, cleanup of obsolete/dead code etc.) has > happened in OpenSSL these days. It's more that there's some myth around > LibreSSL from these early days (where the people behind it raised > back then valid criticism about OpenSSL) than any real value. This is exactly my experience. > > -- > Hanno Böck > https://hboeck.de/ > signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
> On 29 Dec 2020, at 09:13, Marcel Schilling > wrote: > > > I just want to comment that I switched to LibreSSL on several Gentoo > systems years ago and never had any major issues. > I run both desktop and server systems with LibreSSL, based on X and > Wayland. The only issues I ran into is a slight lag of the overlay > behind the main tree so once in a while I had to mask a new version of > some package for a week or so. It is largely one person who is under a lot of stress to provide updated patches ASAP. Some upstreams have made clear they will never accept LibreSSL patches and life becomes harder as they adopt new APIs not yet supported in the Libre variant. TL;DR: I’d be fine with keeping LibreSSL if we had (an influx of) people coming up with patches that are sustainable, upstreamed, and not just crippling functionality. > So from a pure user perspective, thing change would mean a risky update > to systems running stable for years with no gain whatsoever. This isn’t quite right. Users cannot upgrade to new versions of software, possibly with security fixes, until a new patch is created and applied. This recently happened with mupdf. One of our developers runs several high-bandwidth Tor relays which were broken with LibreSSL and still haven’t been fixed. But I accept that you’ve had a pain-free experience. > So even if LibreSSL does not provide any advantage over OpenSSL > (anymore), dropping support would do harm. > That said, I do understand maintainer burden and I will probably be fine > with such a change. But I have to say that over the last ten years, > Gentoo does feel a lot less focussed on choice than it used to and I am > counting the days until is deemed 'unpractical' to support legacy boot, > non-systemd init or 'exotic' arches. ;-) > I don’t think this is true. We support equality of openrc vs systemd and if you think there’s deficits there, please let us know - although of course help is welcome (and needed for OpenRC). And on arches, I spend a lot of my time testing packages on various exotic architectures, so it’d be good to have some concrete examples of what’s bothering you. I don’t think being realistic about what we can support is wrong, but I’m also not sure we’ve been particularly aggressive or wrong with any of those decisions... > Best, > Marcel — My position is that I’d prefer to just mask it and make clear it’s unsupported rather than remove at all. There’s little to be gained from fully removing - we can just treat it like musl/prefix/whatever else, i.e. a niche thing which we support with best-effort (and it might be a bit patchy). Thanks, Sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Mon, Dec 28, 2020 at 11:33:36PM +0100, Michał Górny wrote: > On Mon, 2020-12-28 at 22:00 +, Peter Stuge wrote: > > Michał Górny wrote: > > > LibreSSL users, does LibreSSL today have any benefit over OpenSSL? > > > > Yes, at least two: > > > > A. It is a distinct implementation with probably /quite some/ stable > > compatibility, meaning that it will work perfectly fine as an > > alternative in many cases. > > Except that it doesn't, as has been proven numerous times. I just want to comment that I switched to LibreSSL on several Gentoo systems years ago and never had any major issues. I run both desktop and server systems with LibreSSL, based on X and Wayland. The only issues I ran into is a slight lag of the overlay behind the main tree so once in a while I had to mask a new version of some package for a week or so. So from a pure user perspective, thing change would mean a risky update to systems running stable for years with no gain whatsoever. So even if LibreSSL does not provide any advantage over OpenSSL (anymore), dropping support would do harm. That said, I do understand maintainer burden and I will probably be fine with such a change. But I have to say that over the last ten years, Gentoo does feel a lot less focussed on choice than it used to and I am counting the days until is deemed 'unpractical' to support legacy boot, non-systemd init or 'exotic' arches. ;-) Best, Marcel
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Hello, On Mon, 28 Dec 2020, Michal Górny wrote: >The only problem that I can think of are packages that depend >on libressl specifically and do not support openssl. I don't think we >have anything like that but I'll double check. A naive check finds these: Depends unconditionally on dev-libs/libressl: app-crypt/acme-client Depends conditionally on only dev-libs/libressl (no openssl alternative): net-misc/s6-networking net-misc/openntpd HTH, -dnh -- New, from IKEA: DARCKENSE, the chair. Available in white only. All-natural materials! -- Niklas Karlsson
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Michał Górny wrote: > > A. It is a distinct implementation with probably /quite some/ stable > > compatibility, meaning that it will work perfectly fine as an > > alternative in many cases. > > Except that it doesn't, as has been proven numerous times. I'm sure that there are numerous cases where libressl doesn't work, but that's no reason to dismiss cases where it *does*. Did anyone gather actual numbers? > > B. It brings its own TLS API, a unique feature which by itself > > warrants the package. > > ...which by itself has no future That's arrogant and silly coming from anywhere but upstream. You can argue that you will never use the API in your TLS programs, but even then that says really nothing about the API provider itself. > > More elaborate OpenSSL API users can (arguably should) just block on > > libressl instead of requiring patch work. > > It's all nice theory but in practice it means that nobody will be able > to install libressl because some important system packages will block it. Gentoo can't be expected to do magic. If libressl would conflict on another system then of course it will on Gentoo too. Give users more credit here. Also, think more about other use cases than your own. I mentioned one; non-releng stages. The point here is that it's possible to deliberately create a system using libressl by making tradeoffs, e.g. not using some "important" system packages which would block it. Finally, I find it quite beautiful if Gentoo can clearly show that important system packages have slipped far down a monoculture slope - this is a great incentive for new projects which tackle creating alternatives for those packages. > waste our users' time pretending that we do support LibreSSL, > while anyone actually trying it will hit a brick wall. You shouldn't pretend to be something you are not. With a little effort to set users' expectations according to the technical reality (a function of upstreams; rather unrelated to Gentoo) I don't expect wasted time. //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Mon, 2020-12-28 at 22:00 +, Peter Stuge wrote: > Michał Górny wrote: > > I would like to discuss the possibility of discontinuing LibreSSL > > support in Gentoo in favor of sticking with OpenSSL. > > I think that's a horrible idea, since Gentoo is about choice and this > particular component is one of the most important in a system. > > But "support" can mean different things... > > > > LibreSSL users, does LibreSSL today have any benefit over OpenSSL? > > Yes, at least two: > > A. It is a distinct implementation with probably /quite some/ stable > compatibility, meaning that it will work perfectly fine as an > alternative in many cases. Except that it doesn't, as has been proven numerous times. > > B. It brings its own TLS API, a unique feature which by itself > warrants > the package. ...which by itself has no future and only means some people will create less portable applications and then regret it. > > > > All this considered, provided that nobody is able to find a good > > reason > > to use LibreSSL, I would like to propose that we stop patching > > packages, discontinue support for it and last rite it. > > There is no reason at all to do all three of those atomically: > > 1. Stop patching packages to make them build also against libressl > 2. Stop maintaining libressl-*.ebuild > 3. package.mask > > I think the complaint is really only about 1. and I can understand > that the effort here outweighs the perceived benefit, that's fine, > I don't think it's the responsibility of Gentoo developers to patch > the world to build also against libressl. > > But as long as a single package can be built with either openssl or > libressl without changes I consider it appropriate to maintain both > libressl ebuilds and either virtual/openssl or another way to decide > system-wide to use libressl instead of openssl. This remains very > valuable especially for non-releng stages. > > More elaborate OpenSSL API users can (arguably should) just block on > libressl instead of requiring patch work. It's all nice theory but in practice it means that nobody will be able to install libressl because some important system packages will block it. So we'd effectively waste our users' time pretending that we do support LibreSSL, while anyone actually trying it will hit a brick wall. This sounds like the argument 'let's not remove broken packages, people can read the 5 page forum thread on how to get them to work, somewhat!'. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
I've been kindly asked by a gentoo dev to send my two pence in here: peter: > Michał Górny wrote: > > > LibreSSL users, does LibreSSL today have any benefit over OpenSSL? > > Yes, at least two: > > [...] > > B. It brings its own TLS API, a unique feature which by itself warrants > the package. Yeah, since openssl and libressl cannot be installed at the same time, I wonder what will be the future of libtls? To recall, it is a "a new TLS library, designed to make it easier to write foolproof applications" (see libressl.org). I've been using it for some time. It's great, and it is part of libressl. Another thing: Besides libressl there are boringssl and others. Even if still not the case (?), having virtual alternatives should in theory help keeping polished interfaces. If for whatever reason this not the case in practise, I believe dropping the alternatives should be worse. I cannot judge on the work the maintainers have to deal with compatibility issues between libressl and openssl, though. Let me know when I can help.
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Michał Górny wrote: > I would like to discuss the possibility of discontinuing LibreSSL > support in Gentoo in favor of sticking with OpenSSL. I think that's a horrible idea, since Gentoo is about choice and this particular component is one of the most important in a system. But "support" can mean different things... > LibreSSL users, does LibreSSL today have any benefit over OpenSSL? Yes, at least two: A. It is a distinct implementation with probably /quite some/ stable compatibility, meaning that it will work perfectly fine as an alternative in many cases. B. It brings its own TLS API, a unique feature which by itself warrants the package. > All this considered, provided that nobody is able to find a good reason > to use LibreSSL, I would like to propose that we stop patching > packages, discontinue support for it and last rite it. There is no reason at all to do all three of those atomically: 1. Stop patching packages to make them build also against libressl 2. Stop maintaining libressl-*.ebuild 3. package.mask I think the complaint is really only about 1. and I can understand that the effort here outweighs the perceived benefit, that's fine, I don't think it's the responsibility of Gentoo developers to patch the world to build also against libressl. But as long as a single package can be built with either openssl or libressl without changes I consider it appropriate to maintain both libressl ebuilds and either virtual/openssl or another way to decide system-wide to use libressl instead of openssl. This remains very valuable especially for non-releng stages. More elaborate OpenSSL API users can (arguably should) just block on libressl instead of requiring patch work. //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On 12/28/20 8:55 PM, Michał Górny wrote: I might be wrong but I think the update should proceed cleanly with --changed-use/--newuse. Maybe it is worth to tell people within the news item to run sth like emerge --fetchonly dev-libs/openssl net-misc/openssh net-misc/wget before (to have at least the wget sources at disk before it becomes temporary broken during @preserved-rebuild) ? IIRC I needed it to switch from OpenSSL to LIbreSSL at my server and desktop (and coded it therefore into the tinderbox script too). Beside that: years ago I really believed in LibreSSL - *schnief*, *schluchz* -- Toralf PGP 23217DA7 9B888F45 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Mon, 2020-12-28 at 13:59 -0500, Anthony G. Basile wrote: > On 12/28/20 3:56 AM, Michał Górny wrote: > > Hello, developers and Gentoo LibreSSL team. > > > > TL;DR: is there really a point in continuing the never-ending > > always- > > regressing struggle towards supporting LibreSSL in Gentoo? > > > > > > I would like to discuss the possibility of discontinuing LibreSSL > > support in Gentoo in favor of sticking with OpenSSL. Similarly how > > we > > ended up deciding that fighting for libav was unpractical and the > > vast > > majority of users are using ffmpeg (because they didn't really have > > a choice), today it seems that LibreSSL is suffering the same fate. > > > > LibreSSL users, does LibreSSL today have any benefit over OpenSSL? > > To be honest, I don't think so. In 2014, it might have represented > > a new quality. But today, OpenSSL is alive and kicking, and > > LibreSSL > > finds it hard to keep up. > > > > The vast majority of software is not tested against LibreSSL. > > While > > patches are usually trivial and we have people that submit them, > > I find many of them short-sighted. Just look at [1]. Sure, it > > fixes > > the build today but it disabled the feature for all foreseeable > > future. > > How likely is it that somebody will submit another patch reenabling > > it > > with a future LibreSSL version? > > > > While normally I strongly prefer submitting such patches upstream, > > that > > makes things even worse. I mean, I wouldn't be surprised if there > > were > > dozens of packages today that are crippled with LibreSSL just > > because > > somebody fixed the build in the past and never revisited the > > problem. > > > > This somewhat resembles running in circles. Packages kept being > > broken > > with LibreSSL because rarely anyone is using it. And rarely anyone > > is > > using LibreSSL because the apparent benefit (or lack thereof) does > > not > > justify the constant breakage (plus invisible regressions). > > > > All this considered, provided that nobody is able to find a good > > reason > > to use LibreSSL, I would like to propose that we stop patching > > packages, discontinue support for it and last rite it. > > > > > > [1] https://761981.bugs.gentoo.org/attachment.cgi?id=679892 > > > > I'm the current project lead. I inherited it back in the day from > hasufel. It originally had promise of being better than openssl with > 100% compatibility. I hung on because I trusted that team but it has > become more of a hassle than its worth. I am in favor of removing > it. > If we decide to do so, how should we proceed? I think the usual plan for this kind of thing is to: 1. Issue a news item with the planned cutoff date, and suggest people that they can set USE=-libressl to switch earlier. 2. At the cutoff date, use.mask libressl flag. 3. package.mask libressl itself to give people a clear message. I might be wrong but I think the update should proceed cleanly with --changed-use/--newuse. The PM will trigger the rebuilds, and preserved-libs should take care of keeping libressl libs for as long as necessary (yeah, I know relying on preserved-libs sucks). The only problem that I can think of are packages that depend on libressl specifically and do not support openssl. I don't think we have anything like that but I'll double check. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On 12/28/20 3:56 AM, Michał Górny wrote: > Hello, developers and Gentoo LibreSSL team. > > TL;DR: is there really a point in continuing the never-ending always- > regressing struggle towards supporting LibreSSL in Gentoo? > > > I would like to discuss the possibility of discontinuing LibreSSL > support in Gentoo in favor of sticking with OpenSSL. Similarly how we > ended up deciding that fighting for libav was unpractical and the vast > majority of users are using ffmpeg (because they didn't really have > a choice), today it seems that LibreSSL is suffering the same fate. > > LibreSSL users, does LibreSSL today have any benefit over OpenSSL? > To be honest, I don't think so. In 2014, it might have represented > a new quality. But today, OpenSSL is alive and kicking, and LibreSSL > finds it hard to keep up. > > The vast majority of software is not tested against LibreSSL. While > patches are usually trivial and we have people that submit them, > I find many of them short-sighted. Just look at [1]. Sure, it fixes > the build today but it disabled the feature for all foreseeable future. > How likely is it that somebody will submit another patch reenabling it > with a future LibreSSL version? > > While normally I strongly prefer submitting such patches upstream, that > makes things even worse. I mean, I wouldn't be surprised if there were > dozens of packages today that are crippled with LibreSSL just because > somebody fixed the build in the past and never revisited the problem. > > This somewhat resembles running in circles. Packages kept being broken > with LibreSSL because rarely anyone is using it. And rarely anyone is > using LibreSSL because the apparent benefit (or lack thereof) does not > justify the constant breakage (plus invisible regressions). > > All this considered, provided that nobody is able to find a good reason > to use LibreSSL, I would like to propose that we stop patching > packages, discontinue support for it and last rite it. > > > [1] https://761981.bugs.gentoo.org/attachment.cgi?id=679892 > I'm the current project lead. I inherited it back in the day from hasufel. It originally had promise of being better than openssl with 100% compatibility. I hung on because I trusted that team but it has become more of a hassle than its worth. I am in favor of removing it. If we decide to do so, how should we proceed? -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
If it has any weight: I think I was the first person to build Gentoo with LibreSSL. I support this. I believe pretty much everything that LibreSSL originally was (consistent codingstyle, cleanup of obsolete/dead code etc.) has happened in OpenSSL these days. It's more that there's some myth around LibreSSL from these early days (where the people behind it raised back then valid criticism about OpenSSL) than any real value. -- Hanno Böck https://hboeck.de/
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On lunedì 28 dicembre 2020 09:56:19 CET Michał Górny wrote: > I would like to propose that we stop patching > packages, discontinue support for it and last rite it. +1 -- Agostino
[gentoo-dev] [RFC] Discontinuing LibreSSL support?
Hello, developers and Gentoo LibreSSL team. TL;DR: is there really a point in continuing the never-ending always- regressing struggle towards supporting LibreSSL in Gentoo? I would like to discuss the possibility of discontinuing LibreSSL support in Gentoo in favor of sticking with OpenSSL. Similarly how we ended up deciding that fighting for libav was unpractical and the vast majority of users are using ffmpeg (because they didn't really have a choice), today it seems that LibreSSL is suffering the same fate. LibreSSL users, does LibreSSL today have any benefit over OpenSSL? To be honest, I don't think so. In 2014, it might have represented a new quality. But today, OpenSSL is alive and kicking, and LibreSSL finds it hard to keep up. The vast majority of software is not tested against LibreSSL. While patches are usually trivial and we have people that submit them, I find many of them short-sighted. Just look at [1]. Sure, it fixes the build today but it disabled the feature for all foreseeable future. How likely is it that somebody will submit another patch reenabling it with a future LibreSSL version? While normally I strongly prefer submitting such patches upstream, that makes things even worse. I mean, I wouldn't be surprised if there were dozens of packages today that are crippled with LibreSSL just because somebody fixed the build in the past and never revisited the problem. This somewhat resembles running in circles. Packages kept being broken with LibreSSL because rarely anyone is using it. And rarely anyone is using LibreSSL because the apparent benefit (or lack thereof) does not justify the constant breakage (plus invisible regressions). All this considered, provided that nobody is able to find a good reason to use LibreSSL, I would like to propose that we stop patching packages, discontinue support for it and last rite it. [1] https://761981.bugs.gentoo.org/attachment.cgi?id=679892 -- Best regards, Michał Górny
