Per gentoo-dev discussion: https://archives.gentoo.org/gentoo-dev/message/9a92320c599e63c8c18b2ed29050f22f It seems that the majority of developers replying to that mail, including LibreSSL team lead, have agreed to discontinue support for LibreSSL. The proposed plan is to: 1. Prepare for switching systems back to OpenSSL: 1a. Look into USE=bindist updates related to patents expiring in 2021. 1b. Resolve packages not supporting dev-libs/openssl. 2. Publish a news item requesting users to switch back to OpenSSL, including the rationale, appropriate warnings and timeline. 3. After 2-4 weeks, use.mask libressl-related flags and therefore cease support for LibreSSL. The existing support will still be usable for some time. 4. Eventually last rite and remove dev-libs/libressl. We should have at least an approximate date for that, though it largely depends on when removing downstream patching will render it unusable.
As a user I am not involved in gentoo-dev discussions. However, as someone who does use LibreSSL, I hope that there will still be a way to continue using it. (It still seems actively developed to me!: https://www.libressl.org/releases.html ) I see there is an overlay on Github. ( https://github.com/gentoo/libressl ) If dev-libs/libressl continues to exist there, will there still be a way to install it without a ton of openssl [B] blockers preventing me from even using the overlay? I know in the past default profiles have been modified to mask things which Gentoo devs no longer wish to support. [rant]I realize it's a pain to continue patching upstream, but it feels like there will be no USEFLAGs left at all. In the few years I've used Gentoo, more and more use flags are going away and it is becoming less and less customizable. It seems like I get a news notification every other week from Michał Górny letting me know Gentoo is not going support package X or use X that I have been using for months. Gentoo could consider throwing it's weight around at upstream to implement these patches rather than caving and throwing in the towel on various good projects over the years.[/rant]
(In reply to tonemgub from comment #1) > I see there is an overlay on Github. ( https://github.com/gentoo/libressl ) > If dev-libs/libressl continues to exist there, will there still be a way to > install it without a ton of openssl [B] blockers preventing me from even > using the overlay? I know in the past default profiles have been modified to > mask things which Gentoo devs no longer wish to support. It would either be possible via adding dev-libs/openssl to package.provided, or alternatively adding a meta-ebuild dev-libs/openssl (that pulls libressl in) to the overlay. In either case, our existing tooling can handle this. > [rant]I realize it's a pain to continue patching upstream, but it feels like > there will be no USEFLAGs left at all. In the few years I've used Gentoo, > more and more use flags are going away and it is becoming less and less > customizable. It seems like I get a news notification every other week from > Michał Górny letting me know Gentoo is not going support package X or use X > that I have been using for months. Gentoo could consider throwing it's > weight around at upstream to implement these patches rather than caving and > throwing in the towel on various good projects over the years.[/rant] I don't really understand what you expect to happen but I think you overestimate Gentoo's 'weight'. If we were to declare that we are going to boycott Qt until they officially support LibreSSL... people will either think it's a bad joke, or be pretty annoyed about it. How would that happen anyway? Are we going to stop upgrading Qt and let our users suffer because of bugs? Voice some meaningless vocal protest? Honestly, I don't see that kind of thing happening unless a few major distros all agree on it. And then, we're talking about binary distros that can't reasonably support both options or provide a clean transition period. And they don't have any stake in switching to LibreSSL either. This is as if you created a new SSL library, let's call it MyTLS, and then demanded that every upstream merges MySSL support patches from you. Sure, many people will do that because why not. Some will ask what's that library and why support it in the first place if 'nobody is using it' [yet]? It will take some time and work to convince more projects to support it, and it is doubtful to happen unless you have some advantage against the competition. And now imagine that some of the people you've convinced already learn that new version of MyTLS broke the API and they have to merge another set of patches. Or that the new feature they'd like to implement doesn't have matching support in MyTLS and you're not planning to implement it. This is pretty much where people are with LibreSSL right now.
Will the LibreSSL package be available via the LibreSSL overlay, or will I have to add it to my own overlay? Also for those worried about OpenSSL blocking perfectly fine packages that can easily use LibreSSL, just add dev-libs/openssl to your package.provided.
(In reply to Not Baobab from comment #3) > Will the LibreSSL package be available via the LibreSSL overlay, or will I > have to add it to my own overlay? What would be the purpose of LibreSSL overlay if it didn't supply LibreSSL?
(In reply to Michał Górny from comment #4) > (In reply to Not Baobab from comment #3) > > Will the LibreSSL package be available via the LibreSSL overlay, or will I > > have to add it to my own overlay? > > What would be the purpose of LibreSSL overlay if it didn't supply LibreSSL? True.
PMASK incoming. The initial removal date is in 3 months, as suggested in the mail. We can prolong it later if necessary.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=afbeb5c34227caae0b1bacc04a1d687892efc0d5 commit afbeb5c34227caae0b1bacc04a1d687892efc0d5 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2021-02-01 10:02:30 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2021-02-01 10:06:46 +0000 package.mask: Last rite dev-libs/libressl Bug: https://bugs.gentoo.org/762847 Signed-off-by: Michał Górny <mgorny@gentoo.org> profiles/base/use.mask | 5 +++++ profiles/package.mask | 7 +++++++ 2 files changed, 12 insertions(+)
Can this please be reconsidered? I know its a lot of extra work to maintain libressl when some upstream projects will not merge patches, but now that alpine, gentoo and void do not carry or plan to drop libressl there aren't any other non-niche distros I know that support it meaning the support in the upstream libressl-portable repo may suffer as well. Sure user's can use a third party overlay, but this carries two additional issues. 1. This requires user's to trust multiple repos instead of just one, for something as critical as ssl this is not ideal because the repo with far fewer eyes on it may lag behind on important security issues or inadvertently introduce new ones that may not be noticed as quickly if at all. 2. This puts all the trust for most gentoo user's into a single ssl implementation, openssl. With both openssl and libressl if either has any undiscovered or not yet introduced vulnerabilities the user's can just switch until the fix is implemented. Additionally with only one choice a bad actor will have a much wider attack range.
Gone
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=330f859dc9219e3de802718bbb002bfa29fa03dc commit 330f859dc9219e3de802718bbb002bfa29fa03dc Author: Sam James <sam@gentoo.org> AuthorDate: 2021-05-01 18:12:47 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-05-01 18:24:05 +0000 profiles: drop obsolete LibreSSL mask Bug: https://bugs.gentoo.org/762847 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 7 ------- 1 file changed, 7 deletions(-)
