Re: [gentoo-dev] Re: [gentoo-dev-announce] We are finally shutting down CVS
On Sun, Dec 27, 2020 at 10:31 AM Alec Warner wrote: > > On Sun, Dec 27, 2020 at 6:39 AM Ulrich Mueller wrote: > > > > > On Sun, 27 Dec 2020, Max Magorsch wrote: > > > > > To access the old repositories you can use gitweb.gentoo.org instead. > > > We have migrated all old cvs repositories to git. All of them are > > > available read-only now at [0]. > > > > I've just looked at > > https://sources.gentoo.org/archive/cvs/gentoo.git/ > > and its commit history ends in 2004. > > > > Can you please reinstate CVS until a more accurate conversion is > > available? > > I'm happy to make tarballs available (as discussed in a bunch of > places on irc.) Is that sufficient or is there some particular > requirement for the CVS protocol specifically? So some updates: - We will make tarballs of the raw CVS repos available soon; I'm working with ulm@ to remove various PII in some places; we previously used CVS ACLs to prevent people from seeing this PII and we will similarly remove it in these tarballs. - Sources.gentoo.org (used to browse cvs repositories) is now gone. - https://sources.gentoo.org now points at gitweb.gentoo.org, but we may point it at https://anongit.gentoo.org in the future. - The viewvc instance that powered cvs browsing was deleted and isn't coming back and the basic idea is that we will serve archival tarballs (for really old stuff) and git (for modern stuff) and nothing else. Thanks to ulm (for reviewing the cvs content) and arzano (who is doing all the actual work underneath ;p) Also some clarification here. Infra has carried some tech debt for 5 years[0] and this mostly worked OK for us. However cfengine2 is *really* old and we need to get off of it. Most new services run on top of 'puppet' a 'newer' management stack that helps us configure machines and services. So this push to retire a bunch of stuff is aligned with a push to get off of cfengine completely by EOY because it's starting to really cause us operational challenges. Antarus is not just arbitrarily shutting stuff off; but we are also in a bit of a rush at the end of 2020 so the shutdowns are not as smooth as we would like. -A [0] I checked, we started to migrate to puppet in *2010* and are still migrating, 10 years later ;P > > -A > > > > > Same applies to gentoo-x86 where the git repo misses whole categories. > > > > Ulrich
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] [TINDERBOX] A round with dev-lang/python-exec[-native-symlinks]
On martedì 29 dicembre 2020 13:03:07 CET Michał Górny wrote: > @ago, could you make sure that the tinderbox tells people to read up > on the tracker? I added the note. However the first thing I would to do in reports like this is at least click on the tracker bug. -- Agostino
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] [TINDERBOX] A round with dev-lang/python-exec[-native-symlinks]
On Tue, 2020-12-29 at 13:57 +0200, Joonas Niilola wrote: > > > On 12/29/20 1:51 PM, Agostino Sarubbo wrote: > > Hello, > > > > as requested by mgorny, the tinderbox is doing a round with dev- > > lang/python- > > exec[-native-symlinks]. > > > > Please expect related bugs. > > > > The tracker is at: https://bugs.gentoo.org/762406 > > > > -- > > Agostino > > > > > > > Could we have some sort of summary in here what this means, and an > example to fix issues? Please? I will summarize it on the tracker in a few minutes. @ago, could you make sure that the tinderbox tells people to read up on the tracker? -- Best regards, Michał Górny
Re: [gentoo-dev] [TINDERBOX] A round with dev-lang/python-exec[-native-symlinks]
On 12/29/20 1:51 PM, Agostino Sarubbo wrote: > Hello, > > as requested by mgorny, the tinderbox is doing a round with dev-lang/python- > exec[-native-symlinks]. > > Please expect related bugs. > > The tracker is at: https://bugs.gentoo.org/762406 > > -- > Agostino > > > Could we have some sort of summary in here what this means, and an example to fix issues? Please? -- juippis OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [TINDERBOX] A round with dev-lang/python-exec[-native-symlinks]
Hello, as requested by mgorny, the tinderbox is doing a round with dev-lang/python- exec[-native-symlinks]. Please expect related bugs. The tracker is at: https://bugs.gentoo.org/762406 -- Agostino
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
