Re: small logic issue with system upgrades
On Wed, May 22, 2024 at 4:34 PM Marius Schwarz wrote: > ATM I'm upgrading a remote server from F38 to F39 via SSH login. > > The bash runs a screen, so if ssh or the network dies, the upgrade can > continue. > > I just noticed that even if it keeps running, it's useless because > openssl und openssh do not get upgraded after another. > > So, atm, the server has a sshd that says, that openssl is newer as the > required openssl version. It does not start it nor can the running sshd, > that runs the upgrade connection, fork a new instance. In other words: > no login possible to rescue or recover the upgrade session remotely. > > if that wasn't enough, imapd and other services do also refuse to work > due to openssl version mismatch. > > I can imagine, that this class of problems is not soley with openssl. > > O== Changerequest > > find a way to cluster packages close together that need openssl, to keep > the risk of an inaccessible server small. > > i.e. by grouping the packages i.e. "network" "office" etc. Were you following the steps outlined in https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline ? -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Switching XZ for ZSTD?
On Thu, Apr 4, 2024 at 8:00 PM Arnie T via devel wrote: > > Hello Kevin, > > > I'm hopeful some things will come out of this as it's a chance for us to > > look at our processes and improve them. > > I'm glad that's happening. It seems to me that improving those processes > would be Distro decisions. Which I keep understanding don't really exist. > At least not quickly. > So I'm confused still. But glad. > > > > > 1] Lack of committer 'Real' identity confidence and verification is a > > > problem. > > > IMHO this isn't a problem. We don't have a right to demand anything from > > open source projects. We can ask, we can urge, we can contribute and > > change things, we can choose to not use something, or fork something. > > I really don't suggest 'demanding' anything. I do think it's wise to make > choices to avoid it. Like just my example of a critical-path XZ with one > developer vs a critical-path ZSTD built & maintained in a Facebook FOSS > project. > > I know from just a business view I would never enter into a 'critical' > contract without "knowing" the principal persons. Of course you must know > what you need "knowing" to be. Careful, for now you're approaching another scalability issue of the community development model. I mean, as chill as he is, even Daniel Stenberg [1] must have a limit on the amount of beers he can handle. > > > 2] Undetected differences source + packaging in repo vs tarballs are > > > unchecked. > > > > > > Yeah, a lot of the discussion has been in this area. > > > > I'm wondering if perhaps we shouldn't revisit source-git, or at least > > a variant of it where we keep the upstream sources in a branch always > > and apply packaging on top of that and build from there. > > I'm not sure what the packaging tools and rules are here. > It seems to me that repo source with an attested commit (signature? published > hash?) can serve as the one source of truth. > Then users can pull the commit or the on-demand API-generated tarball. I > guess that could be subject to for example Github's or Gitlab's API tarball > generators being hacked. But that seems less probable of a concern. > > > > 3] Under-resourced development creates risk; 'Many eyes' bench depth in > > > development is needed. > > > > Yep. I think also visibility of changes can be improved. > > So, maintainers know more about whats in a new version and how it works. > > You can implement tools to increase the visibility for sure. And procedures. > > Also just the "given enough eyeballs, all bugs are shallow" that comes with > using a larger project helps. > > Thanks for the discussion. > > Cheers! > > Arnie [1] https://daniel.haxx.se -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
On Wed, Mar 20, 2024 at 6:52 PM Ali Erdinc Koroglu wrote: > > > > On 08/03/2024 22:37, Aoife Moloney wrote: > > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine > > > > This is a proposed Change for Fedora Linux. > > This document represents a proposed Change. As part of the Changes > > process, proposals are publicly announced in order to receive > > community feedback. This proposal will only be implemented if approved > > by the Fedora Engineering Steering Committee. > > > > == Summary == > > We disable support of engines in OpenSSL > > > > == Owner == > > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]] > > * Email: dbely...@redhat.com > > > > == Detailed Description == > > We are going to build OpenSSL without engine support. Engines are not > > FIPS compatible and corresponding API is deprecated since OpenSSL 3.0. > > The engine functionality we are aware of (PKCS#11, TPM) is either > > covered by providers or will be covered soon. > > > > == Feedback == > > > > > > == Benefit to Fedora == > > We get rid of deprecated functionality and enforce using up-to-date > > API. Engine support is deprecated in OpenSSL upstream, and after > > provider migration caused some deficiencies with engine support. No > > new features will be added to the engine. So we reduce the maintenance > > burden and potentially attack surface. > > > > It follows the approach planned for CentOS 10. > > Hi, > We're providing the Intel QuickAssist Technology OpenSSL Engine (QAT_Engine)* > in Fedora and RHEL. > I think we shouldn't rush things to have no-engine environment. > > * : > https://www.redhat.com/en/blog/accelerated-encryption-4th-gen-intelr-xeonr-scalable-processors QAT can be built with --enable-qat_provider: https://github.com/intel/QAT_Engine/blob/1d248f28a10123f3a681b9910283d6e66e3f7dc1/configure.ac#L173 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: So you can't just copy 'sources' from one package to another?
On Fri, Mar 8, 2024 at 5:19 PM Richard W.M. Jones wrote: > > For mingw-* packages we (sometimes) have a separate package from the > native package, eg. libgcrypt vs mingw-libgcrypt. Therefore two > different packages are sometimes built with the exact same sources. > > However I discovered copying 'sources' (ie the file) from libgcrypt > dist-git to mingw-libgcrypt dist-git alone isn't sufficient to get the > package to build. You still have to download the source tarballs in > libgcrypt, copy them to mingw-libgcrypt, and 'fedpkg new-sources > ' to upload them again. > > Isn't the lookaside cache shared across the whole of Fedora? Fedora's lookaside schema seems to be https://src.fedoraproject.org/repo/pkgs/rpms/$pkgname/$filename/$hashtype/$hash/$filename, so it far from being a content-addressed storage that'd reuse data across different $pkgnames. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: status openssl1.1
On Mon, Oct 16, 2023 at 8:55 AM josef radinger via devel wrote: > openssl1.1 reached EOS on recently (11th September 2023 I assume) > https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ > > according to > https://www.openssl.org/source/: > ... > The previous LTS version (the 1.1.1 series) is also available but has > recently gone out of support. > ... > > paid extended support for 1.1.1 would be available, but is maybe not the > way to go for fedora. > > we have > https://fedoraproject.org/wiki/Changes/DeprecateOpensslCompat#Upgrade/compatibility_impact > with no changes since 2022 > and a closed tracker bug at > https://bugzilla.redhat.com/show_bug.cgi?id=2108694 > > maybe we should start deprecating that package? Sorry, WDYM by "start deprecating this package"? The change you've linked to is ChangeAcceptedF37, and starting from f37 the package `Provides: deprecated()` https://src.fedoraproject.org/rpms/openssl1.1/c/ae8d635798dd50528986c1702475428c876a3a54?branch=f37 What other steps do you have in mind? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to tighten RPM crypto-policy back
On Tue, Sep 19, 2023 at 11:19 AM Alexander Sosedkin wrote: > > Hello, > > 6 months ago, there's been a F38 blocker: https://pagure.io/fesco/issue/2960 > Long story short: > RPM has moved to sequoia, > sequoia has started respecting crypto-policies, > Google repos have been signed with a 1024-bit DSA key, > Google Chrome was not installable => F38 blocker. > Back at the time, it's been hastily "resolved" > by relaxing RPM security through crypto-policies > just enough to tolerate that Google signature: > https://bugzilla.redhat.com/show_bug.cgi?id=2170878 > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129 > > Since then it has been brought to my attention that > Google has now added a 4096 bit RSA key > https://www.google.com/linuxrepositories/ > (EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796) > > Because of that, I'd like to revert that RPM policy relaxation > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5 > in (f39) rawhide and align RPM security with the rest of the policy. > > Thoughts / feedback? OK, I've messed up. Clemens Lang has kindly pointed me at a flaw in my testing. Basically, nothing is as rosy as I've previously shown because of SHA-1 signatures in the keys. In fact, even Chrome can't be installed with the change properly reverted. Guess I'll have to shelve the wide discussion for a while, we aren't ready. =( Sorry for taking your time. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to tighten RPM crypto-policy back
On Wed, Sep 27, 2023 at 2:38 PM Stephen Gallagher wrote: > > On Wed, Sep 27, 2023 at 7:06 AM Alexander Sosedkin > wrote: > ... > > Feel free to strike down these proposals > > using whatever mechanisms Fedora governance offers. > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3 > > rejection suggests they do work. > > To be clear, that one was rejected primarily because of Chrome and > VSCode (both extremely important to our user-base), which appear to > have been resolved since then. I'm definitely in favor of tightening > things up at this point. You're probably thinking about the revert I wanna revert: https://pagure.io/fesco/issue/2960. StrongCryptoSettings3 was a different, more ambitious thing, where preventing openssl from trusting SHA-1 signatures was the contention point that prevented it from happening. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to tighten RPM crypto-policy back
On Tue, Sep 26, 2023 at 7:40 PM Kevin Kofler via devel wrote: > > Alexander Sosedkin wrote: > > Because of that, I'd like to revert that RPM policy relaxation > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5 > > in (f39) rawhide and align RPM security with the rest of the policy. > > > > Thoughts / feedback? > > I am still opposed, because it is still a backwards-incompatible change that > breaks existing repositories (such as my Calcforge one) just so that someone > can tick a checkbox on some "security" checklist. Yes, those who want to trust that key you've generated back in 2007 will have to use LEGACY policy or relax it in some other way unless you generate a stronger key, that's precisely my intention. I'm sorry for putting extra work on you, this is never pleasant, but, all things considered, I find it well worth the benefit. If you like *your* systems insecure, I do respect that choice of yours, and I strive to offer a convenient opt-out of "security" that should let you lag behind the modern world by ~5 extra years. But we do need secure *defaults*, and I hope that you see how compromising the security of most of the of installations at the expense of the convenience of a few packagers doesn't seem like the right course to me. I often joke that the four Fedora values are "Freedom", "Friends", "Features" and "Fecurity" but, jokes aside, "First" still made that list: https://docs.fedoraproject.org/en-US/project/#_first and my reading of it is that "15 years of backwards compatibility no matter what" is explicitly a non-goal. Fedora defaults are already lagging significantly behind, say, RHEL-9, but there must be some limit to accepting insecure legacy stuff by default, and I'll keep proposing the limits I find sensible until I get completely disappointed in this distro. Feel free to strike down these proposals using whatever mechanisms Fedora governance offers. https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3 rejection suggests they do work. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to tighten RPM crypto-policy back
On Tue, Sep 26, 2023 at 7:47 PM Peter Robinson wrote: > > On Tue, Sep 19, 2023 at 10:20 AM Alexander Sosedkin > wrote: > > > > Hello, > > > > 6 months ago, there's been a F38 blocker: https://pagure.io/fesco/issue/2960 > > Long story short: > > RPM has moved to sequoia, > > sequoia has started respecting crypto-policies, > > Google repos have been signed with a 1024-bit DSA key, > > Google Chrome was not installable => F38 blocker. > > Back at the time, it's been hastily "resolved" > > by relaxing RPM security through crypto-policies > > just enough to tolerate that Google signature: > > https://bugzilla.redhat.com/show_bug.cgi?id=2170878 > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129 > > > > Since then it has been brought to my attention that > > Google has now added a 4096 bit RSA key > > https://www.google.com/linuxrepositories/ > > (EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796) > > > > Because of that, I'd like to revert that RPM policy relaxation > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5 > > in (f39) rawhide and align RPM security with the rest of the policy. > > > > Thoughts / feedback? > > I think it should be done as a system wide change so it can have the > appropriate review but it seems we're better off than we were. System-wide or self-contained? I'm not altering the system-wide default, I'm removing the exception that was limited to rpm/dnf in scope to bring them in line with system-wide default; but rpm/dnf are kinda important. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to tighten RPM crypto-policy back
On Tue, Sep 19, 2023 at 7:47 PM Kevin Fenzi wrote: > > On Tue, Sep 19, 2023 at 11:19:18AM +0200, Alexander Sosedkin wrote: > > Hello, > > > > 6 months ago, there's been a F38 blocker: https://pagure.io/fesco/issue/2960 > > Long story short: > > RPM has moved to sequoia, > > sequoia has started respecting crypto-policies, > > Google repos have been signed with a 1024-bit DSA key, > > Google Chrome was not installable => F38 blocker. > > Back at the time, it's been hastily "resolved" > > by relaxing RPM security through crypto-policies > > just enough to tolerate that Google signature: > > https://bugzilla.redhat.com/show_bug.cgi?id=2170878 > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129 > > > > Since then it has been brought to my attention that > > Google has now added a 4096 bit RSA key > > https://www.google.com/linuxrepositories/ > > (EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796) > > > > Because of that, I'd like to revert that RPM policy relaxation > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5 > > in (f39) rawhide and align RPM security with the rest of the policy. > > > > Thoughts / feedback? > > It might be good to go through all the ones that were hit by this (it > wasn't just chrome) and indicate if they are now fixed. > You can see a partial list in the common bug: > > https://discussion.fedoraproject.org/t/popular-third-party-rpms-fail-to-install-update-remove-due-to-security-policies-verification/70498 > > and in the discussion off it. Whoa, that's too many, I suspect misreporting. I seriously doubt they were all really using DSA-1024 and switched over. But if that really was the case --- great job to all of them. > The list from there: > Google Chrome (RPM signature rejected, repo key rejected) Repo has added RSA-4096, RPM is signed with SHA-512, installs > Microsoft Edge (repo key rejected) RSA-2048, RPM is signed with SHA-256, installs > Dropbox (repo key rejected) RSA-2048, RPM is signed with SHA-512 > Skype (repo key rejected) RSA-2048 / SHA-512 > Visual Studio Code (repo key rejected) RSA-2048 / SHA-256 (let's name a package `code`. outstanding move) > Sublime Text (repo key rejected) RSA-4096 / SHA-256 > Microsoft Teams (repo key rejected) RSA-2048, but https://packages.microsoft.com/yumrepos/ms-teams/repodata looks barren > TeamViewer (repo key rejected) RSA-4096 / SHA-256 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to tighten RPM crypto-policy back
On Tue, Sep 19, 2023 at 12:44 PM Miroslav Suchý wrote: > > Dne 19. 09. 23 v 11:19 Alexander Sosedkin napsal(a): > > Because of that, I'd like to revert that RPM policy relaxation > > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5 > > in (f39) > > rawhide and align RPM security with the rest of the policy. Thoughts / > > feedback? > > You can try to load the keys from this collection under the tightened policy: > > https://github.com/xsuchy/distribution-gpg-keys/ Awesome suggestion, sorry it took me so long to get back to you. I'm pleased to see that DSA looks dead: * adobe/RPM-GPG-KEY-adobe-linux: 2007-02-28 - inf * calcforge/RPM-GPG-KEY-calcforge: 2007-03-30 - inf * centos/RPM-GPG-KEY-CentOS-5: 2007-01-06 - 2017-01-03 expired * datto/DATTO-LEGACYDIST-PKGS-GPG-KEY: 2016-02-29 - inf * dell/public.key: 2001-04-16 - inf * epel/217521F6.txt: 2007-03-02 - 2017-02-27 expired * epel/RPM-GPG-KEY-EPEL-5: 2007-03-02 - 2017-02-27 expired * fedora/RPM-GPG-KEY-fedora-10-primary: 2008-08-27 - inf * fedora/RPM-GPG-KEY-fedora-10-testing: 2008-08-27 - inf * fedora/RPM-GPG-KEY-fedora-14-s390x: 2010-12-23 - inf * fedora/RPM-GPG-KEY-fedora-8-9-primary: 2008-08-27 - inf * fedora/RPM-GPG-KEY-fedora-8-9-testing: 2008-08-27 - inf * google/linux_signing_key.pub: - has RSA-4096 now as well * jenkins/0x9b7d32f2d50582e6.key: 2009-02-01 - inf (repo has a 2023 version) * jpackage/jpackage.asc: 2002-10-22 - inf * mariadb/RPM-GPG-KEY-MariaDB: 2010-02-02 - inf * mysql/RPM-GPG-KEY-mysql: 2003-02-03 2013-09-18 - 2022-02-16 expired (repo has newer ones in the same directory) * oraclelinux/RPM-GPG-KEY-oracle-el4: 2006-09-05 - 2011-09-04 expired * oraclelinux/RPM-GPG-KEY-oracle-el5: 2007-05-18 - 2015-05-16 expired * postgresql/RPM-GPG-KEY-PGDG: 2008-01-08 - inf * postgresql/RPM-GPG-KEY-PGDG-10: 2008-01-08 - inf * postgresql/RPM-GPG-KEY-PGDG-84: 2008-01-08 - inf * postgresql/RPM-GPG-KEY-PGDG-90: 2008-01-08 - inf * postgresql/RPM-GPG-KEY-PGDG-91: 2008-01-08 - inf * postgresql/RPM-GPG-KEY-PGDG-92: 2008-01-08 - inf * postgresql/RPM-GPG-KEY-PGDG-93: 2008-01-08 - inf * postgresql/RPM-GPG-KEY-PGDG-94: 2008-01-08 - inf * postgresql/RPM-GPG-KEY-PGDG-95: 2008-01-08 - inf * postgresql/RPM-GPG-KEY-PGDG-96: 2008-01-08 - inf * redhat/RPM-GPG-KEY-redhat5-auxiliary: 2006-12-01 - inf * redhat/RPM-GPG-KEY-redhat5-beta: 2002-03-15 - inf * redhat/RPM-GPG-KEY-redhat5-former: 1999-09-23 - inf * redhat/RPM-GPG-KEY-redhat5-release: 2006-12-06 - inf * redhat/RPM-GPG-KEY-redhat5-rhx: 2007-04-17 - inf * redhat/RPM-GPG-KEY-redhat6-beta: 2002-03-15 2009-02-24 - inf * redhat/RPM-GPG-KEY-redhat6-legacy-former: 1999-09-23 - inf * redhat/RPM-GPG-KEY-redhat6-legacy-release: 2006-12-06 - inf * redhat/RPM-GPG-KEY-redhat6-legacy-rhx: 2007-04-17 - inf * redhat/RPM-GPG-KEY-redhat6-release: has RSA-4096 as well * redhat/RPM-GPG-KEY-redhat8-release: has RSA-4096 as well * remi/RPM-GPG-KEY-remi: 2005-04-21 - inf (repo has newer ones) * rpmfusion/RPM-GPG-KEY-rpmfusion-free-el-5: 2008-07-12 - inf * rpmfusion/RPM-GPG-KEY-rpmfusion-nonfree-el-5: 2008-07-12 - inf * scientific-linux/RPM-GPG-KEY-sl: 2009-07-10 - inf (repo has newer ones) * smeserver/RPM-GPG-KEY-SMEServer: 2005-09-30 - inf (repo has newer ones) * suse/RPM-GPG-KEY-SuSE-SLE-10: 2000-10-19 - 2022-03-14 expired (repo has newer ones) * virtualbox/oracle_vbox.asc: 2010-05-18 - inf (repo has newer ones) If that repo's representative of the real world situation, I declare the world ready. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to tighten RPM crypto-policy back
On Tue, Sep 19, 2023 at 11:19 AM Alexander Sosedkin wrote: > > Hello, > > 6 months ago, there's been a F38 blocker: https://pagure.io/fesco/issue/2960 > Long story short: > RPM has moved to sequoia, > sequoia has started respecting crypto-policies, > Google repos have been signed with a 1024-bit DSA key, > Google Chrome was not installable => F38 blocker. > Back at the time, it's been hastily "resolved" > by relaxing RPM security through crypto-policies > just enough to tolerate that Google signature: > https://bugzilla.redhat.com/show_bug.cgi?id=2170878 > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129 > > Since then it has been brought to my attention that > Google has now added a 4096 bit RSA key > https://www.google.com/linuxrepositories/ > (EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796) > > Because of that, I'd like to revert that RPM policy relaxation > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5 > in (f39) rawhide and align RPM security with the rest of the policy. Correction, f40 rawhide. > Thoughts / feedback? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Intention to tighten RPM crypto-policy back
Hello, 6 months ago, there's been a F38 blocker: https://pagure.io/fesco/issue/2960 Long story short: RPM has moved to sequoia, sequoia has started respecting crypto-policies, Google repos have been signed with a 1024-bit DSA key, Google Chrome was not installable => F38 blocker. Back at the time, it's been hastily "resolved" by relaxing RPM security through crypto-policies just enough to tolerate that Google signature: https://bugzilla.redhat.com/show_bug.cgi?id=2170878 https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/129 Since then it has been brought to my attention that Google has now added a 4096 bit RSA key https://www.google.com/linuxrepositories/ (EB4C 1BFD 4F04 2F6D DDCC EC91 7721 F63B D38B 4796) Because of that, I'd like to revert that RPM policy relaxation https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/a12f7b20638be8f872ad1995c7d2edce41c227b5 in (f39) rawhide and align RPM security with the rest of the policy. Thoughts / feedback? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RPM Sequoia: A Sequoia-based backend for the RPM Package Manager
On Thu, Apr 27, 2023 at 12:52 PM Neal H. Walfield wrote: > A year and a half ago, I began working with Panu on using Sequoia as > RPM's OpenPGP parser. I wrote up our journey from the initial > analysis, to adding the code to RPM, and to getting it into Fedora 38 > (yay!) in a blog post. I'm mentioning it here, as I believe it is of > general interest to this community. If this is considered off topic, > I apologize in advance. > > https://sequoia-pgp.org/blog/2023/04/27/rpm-sequoia/ > > :) Neal Well, it sure does relate to Fedora development, and constitutes one thrilling read about a great job done well. Thanks for sharing! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to migrate database format during package update?
On Wed, Feb 1, 2023 at 1:57 PM Milan Crha wrote: > this is a query for an opinion and a best-practice experience for a > case when a package needs to change its internal database format > between versions, in an environment, which does not allow real > migration, aka the app cannot read both formats, it can use one or the > other. > > To be specific, the libdb package is going to be removed [1] sooner or > later, and one of the packages which still use it is Bogofilter [2]. > It's easy to just switch from libdb to SQLite in the .spec file, the > problem is that the years of user's training of the Bogofilter spam/ham > data would be lost by such change. The SQLite version cannot read the > libdb data and vice versa (obviously), thus there needs to be done some > manual migration by the users. The worst, the users may need to export > their wordlist data before the update/upgrade and import it back after > the update/upgrade. Also, when the bogofilter is run with the other > format of the wordlist database, it simply errors out and expects > manual intervention. It's also good, the old data is not completely > lost, after all, and the user is aware something changed. > > My idea was to help the users with the migration in a way that the > export of the libdb data could be done during the package update, in > the %pre stage. A very nasty way I came with is to traverse the /home/ > directories and if there exists the old database, then export it and > rename the old file, thus the new bogofilter can run, even with an > empty database. The thing is that the exported data is ready in such > case, no need to downgrade the package or install old Fedora or any > such thing just to recover the wordlist. It's the only advantage, while > there are many disadvantages: > - it's a nasty approach, the package should not touch users' home > - it works only if the user uses the default/expected setting; saving > the database into a different place voids this best-effort approach > - the exported file is owned by root/admin, which requires change of > the attributes thus the user can get rid of it > - the package cannot tell to the user what to do next, to restore > the exported data. > > I'm sure you might find more disadvantages, these are just the top > four. > > That being said, any such change surely deserves release notes, with > the commands what to do to export and then back import the wordlist. > There should be filled a corresponding Change too, I guess. > > Still, how does other packages migrate their data, or at least help the > users with the migration? Is there any way? cyrus-sasl ships a migration tool for some transition period and suggests the user to manually invoke it: https://src.fedoraproject.org/rpms/cyrus-sasl/blob/rawhide/f/cyrus-sasl-2.1.27-Migration-from-BerkeleyDB.patch Personally, I believe that even automatically converting a database on access and leaving a backup is already borderline risky, as the administrator doesn't know that about the conversion and nobody looks at any logs if things keep working. Please let's not entertain the idea of actively crawling for databases =) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Potential kTLS issue with TLS-PSK, GnuTLS + Rawhide - how to debug it?
On Fri, Nov 25, 2022 at 1:14 PM Richard W.M. Jones wrote: > > Hi Daiki & Frantisek, > > There's a new error that is appearing in the libnbd test suite when > testing TLS-PSK. Regular TLS (with X.509 certs) works fine. It seems > to have started since I upgraded the kernel on my machine from 5.19.0 -> > 6.1.0, and I think it is related to kTLS. > > You may be able to reproduce it fairly easily in Fedora Rawhide, or in > Fedora 37 by upgrading the kernel, nbdkit and libnbd to Rawhide versions. > > $ uname -a > Linux pick.home.annexia.org 6.1.0-0.rc6.46.fc38.x86_64 #1 SMP > PREEMPT_DYNAMIC Mon Nov 21 16:07:44 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux > > $ nbdkit --version > nbdkit 1.33.3 (nbdkit-1.33.3-1.fc38) > $ nbdinfo --version > nbdinfo 1.15.7 > libnbd 1.15.7 > > To reproduce it: > > $ psktool -u bob -p keys.psk > Generating a random key for user 'bob' > Key stored to keys.psk > > $ nbdkit --tls=require --tls-psk=keys.psk null \ >--run 'nbdinfo "nbds://bob@localhost/?tls-psk-file=keys.psk" ' > nbdkit: null[1]: error: gnutls_record_recv: Error in the pull function. > nbdkit: null[1]: error: reading option: conn->recv: Input/output error > nbdinfo: nbd_connect_uri: gnutls_record_recv: Error in the pull function. > > For lots more debugging, use this command instead: > > $ nbdkit -fv --tls=require --tls-psk=keys.psk \ >-D nbdkit.tls.log=99 -D nbdkit.tls.session=1 null \ >--run 'LIBNBD_DEBUG=1 nbdinfo > "nbds://bob@localhost/?tls-psk-file=keys.psk" ' > > The reason I believe it is related to kTLS is because if I do: > > # modprobe -r tls > > then the error goes away. Loading the module makes the error appear > again. (Note that the module appears to be loaded on boot, so this > error will happen for all Rawhide users unless they take special > action.) > > Are there ways to debug kTLS? It seems like there is no kernel output > related to the above failure. > > Are there ways to override GnuTLS automatic detection of kTLS, to > temporarily disable it, even when the kernel module is loaded? For disabling KTLS, try putting ``` [global] ktls = false ``` into `/etc/crypto-policies/local.d/gnutls-no-ktls.config`, and follow up with an `update-crypto-policies --set`. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
On Fri, Nov 11, 2022 at 2:03 PM Florian Weimer wrote: > > * Alexander Sosedkin: > > > On Fri, Nov 11, 2022 at 11:53 AM Petr Pisar wrote: > >> An RPM package itself carry a build time in its RPM header. > >> Are we also going to fake this time in the name of > >> reproducibility? > > > > My opinion: yes, please do (%use_source_date_epoch_as_buildtime). > > And fake the builder hostname (%_buildhost). > > And enable back --enable-deterministic-archives in binutils: > > (https://bugzilla.redhat.com/show_bug.cgi?id=1195883). > > And do whatever else is necessary to stop shipping binary packages > > that users can't reproduce bit-to-bit. > > The downside of doing this is that it's no longer possible to check > whether a build happened against a buildroot with a particular fix in > it. The time-based check was never 100% reliable, but it could be used > as a good indicator in the past. No, no, false dichotomy alert. This is not a case where reproducibility rules out auditability. Not only build system (koji) can track exact versions of builddeps (and if it doesn't, it really should, regardless of reproducibility), I'm not against including builddep versions into the artifacts, in any form, as long as it's done in a reproducible manner. E.g., I have no problem with NixOS having them hashed and used as the installation prefix, not at all. In RPM world, I've even entertained an idea of having a subpackage for auditability not unlike how we have debuginfo, since rebuilding a package reproducibly requires builddep pinning. But if that's avoidable, I'd rather just not mix artifacts with meta. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
On Fri, Nov 11, 2022 at 11:53 AM Petr Pisar wrote: > > V Thu, Nov 10, 2022 at 03:23:49PM -0500, Ben Cotton napsal(a): > > https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes > > > > == Summary == > > > > The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`. > > When an RPM package is built, mtimes of packaged files will be clamped > > to `$SOURCE_DATE_EPOCH` > > Clamp as capping maximal mtime, or resetting mtime for all files? I.e. If > I had a source file dated 1970-01-01 and installed it with "install -p", will > the packaged file retain that 1970-01-01 date, or will it be set to the date > of the latest changlog, e.g. 2022-11-11? In other words, will all files in > a package have the same mtime, or there won't be an mtime newer than the > changelog entry? Second. Original message: >> Clamping means that all files which would otherwise have a >> modification datetime higher than `$SOURCE_DATE_EPOCH` will have the >> modification datetime changed to `$SOURCE_DATE_EPOCH`; files with >> mtime lower (or equal) to `$SOURCE_DATE_EPOCH` will retain the >> original mtimes. > > which is already set to the date of the latest `%changelog` entry. > > What's a changelog entry date in case of rpmautospec changelog? Is it > a git AuthorDate or CommitDate? > > > As a result, more RPM packages will be reproducible: > > Where will this reproducibility stop? Ideally, when it's achieved, and 100% of Fedora will be reproducible under reprotest =P > An RPM package itself carry a build time in its RPM header. > Are we also going to fake this time in the name of > reproducibility? My opinion: yes, please do (%use_source_date_epoch_as_buildtime). And fake the builder hostname (%_buildhost). And enable back --enable-deterministic-archives in binutils: (https://bugzilla.redhat.com/show_bug.cgi?id=1195883). And do whatever else is necessary to stop shipping binary packages that users can't reproduce bit-to-bit. > What value these faked timestamps have? None. > E.g. a compiled file is a function not only of its source, but also of the > compiler. Nods in NixOS. > This proposed change removes > the compiler part from the timestamp. Will timestamps like this be helpful? > Wouldn't be easier to admit that timesamps are nonsense and simply eradicate > all of them stamps from various data formats rather than trying to fake them? > Simply changing rpmbuild to set timestamp to 0 for all contained files, or > removing the time attribute from the RPM format completely? Would be wonderful. Mixing metadata with data has always been a mistake. Reproducibility is at stakes with auditability, and the second must be driven off or given up on. The metainformation of which host has built the artifact and when has no place within the artifact itself. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)
On Tue, Oct 25, 2022 at 7:42 PM Florian Weimer wrote: > > * Alexander Sosedkin: > > > Since it's a build-time-only change, > > can it be rolled out under controlled pressure like this? > > > > 1. every package explicitly opts out (with some macro in specfile, IDK) > > 2. switch gets flipped, nothing changes > > 3. bugs get filed to drop that macro and opt into new behaviour > > 4. opting in gets resolved at a leisurely pace > >across as many releases as needed? > > Sorry, what's the advantage of doing it this way? Spreading out the porting effect =) Maybe I'm scarred by my own unsuccessful attempt to spread out SHA-1 switch flipping across releases, but this sounds like a switch that'll need maintainers to not just react, but also coordinate with upstreams, and Fedora's tight cycle is uncomfortably tight. > We'd have to change all packages that have a C compiler > in their buildroots as part of the first step. OK, maybe just the ones failing to build with C99. > Then we file thousands and thousands of bugs, and hope that > the maintainers take action? I'm not sure that's going to work for > those maintain dozens (hundreds?) of packages. It's also kind of > difficult for a Fedora developer to predict GCC 14 behavior in 2024 > today. > > Relying on individual developer action also means that we'd have to > teach many more people about C arcana and autoconf corner cases. I > don't think that's a good learning investment to be honest. Most of > this knowledge was already obsolete in 1999. > > I don't really know how much time we have before GCC disabled legacy C89 > extensions by default because some of them are incompatible with future > C language directions. I'm not convinced things will resolve themselves > over time. Obviously there's been some progress in the last 25 years > (not everyone uses GCC and Clang with their extensions to build upstream > software), but it's been really slow so far. (Back in 2019, I quickly > found a bunch of really core packages that needed fixes.) It's also not > clear to what degree the Macos efforts that Clemens mentioned have > reached upstreams. It doesn't seeem to have helped the Clang 15 release > much. > > To me, all these things argue against spreading out the porting effort. ¯\_(ツ)_/¯ > I wish we could do it this way, but it doesn't look like it's a feasible > option. One cycle or many, I wish you to find the best way to pull this off. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)
On Tue, Oct 25, 2022 at 5:09 PM Daniel P. Berrangé wrote: > So this change is talking about a new GCC landing in Fedora 40. > > To avoid massive disruption to Fedora though, we need to be doing > work way earlier than the Fedora 40 dev cycle though. > > Identifying all the places where autoconf tests quietly change > their result, and silently toggle on/off alternative code paths > is going to be a big job on its own. > > Once identified there's the even more work to figure out the right > changes needed. I don't know how many packages rely on autoconf, > but the idea of carrying patches in Fedora and re-running autotools > to re-create configure, isn't that appealing on a large scale. > > Obviously the preferred solution is to be able to report the problems > upstream, and get the fixes included in the next upstream release > and then rebase in Fedora. Even better is if a major information > campaign brings this change directly to the attention of upstreams > communities, bypassing the distros where there is an active upstream. > > I'd be concerned about the timeframe for getting through this dance > for a non-negligible number of packages. >> > IOW, this change is talking about something in Fedora 40, but it > feels like the vast majority of work needs to take place in Fedora > 38 and Fedora 39. Fedora 40 neeeds to be nothing more than a "flip > the switch" scenario, otherwise history suggests the change is likely > to end up getting punted to Fedora 41/42. Since it's a build-time-only change, can it be rolled out under controlled pressure like this? 1. every package explicitly opts out (with some macro in specfile, IDK) 2. switch gets flipped, nothing changes 3. bugs get filed to drop that macro and opt into new behaviour 4. opting in gets resolved at a leisurely pace across as many releases as needed? > I feel that this need to start on the prep work in F38/F39 is not > very obvious from the F40 change proposal text. > > So shouldn't we have explicit distinct 'Fedora 38/39' change proposal(s) > to describe the prep work that needs to be done across packages in these > two releases as a matter of urgency, in order to make it possible to the > F40 change to actually happen ? > > > Concretely, as an upstream maintainer, what should they do to test > the behaviour of their code ? Is there more to it than just > setting CFLAGS="-std=gnu99", if they want to validate this in their > upstream CI ahead of GCC 14 arriving ? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
On Wed, Oct 12, 2022 at 4:47 PM Stephen Smoogen wrote: > On Wed, 12 Oct 2022 at 10:32, Kevin P. Fleming wrote: >> On 10/12/22 08:59, Stephen Smoogen wrote: >> > Maybe call it the Fedora Update Manager 'FUM' ? >> >> Unless we're going to call it RUM when it makes its way into RHEL, that >> name may not be the best choice :-) > > Well Red Hat shipped the Yellowdog Update Manager for 2 releases so I am sure > they can go with FUM or RUM (RPM Update Manager).. I would avoid Backup > Upgrade Manager though. Ugh, acronyms, how boring. If we stay true to the abbreviation equilibristics that gave us DNF coming from DaNdiFied YUM, it's only natural to name the ApPoinTed DNF successor APT. =) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Wed, Sep 14, 2022 at 6:40 PM Kevin Fenzi wrote: > > On Wed, Sep 14, 2022 at 11:45:16AM +0200, Alexander Sosedkin wrote: > > On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi wrote: > > > > > > How about this: > > > > > > Drop the term 'jump scare' entirely. IMHO it just sounds bad. > > > > I'm open for proposals on the wording. =) > > Well, I guess it depends on if you still want to implement it and then > plan to roll it back or not... see below. > > > > > Rework the change so it's basically planning on making this change in > > > f38. > > > > That makes it closer than currently, > > defeating the purpose of letting people prepare. > > True, it possibly makes the timeline shorter. > If thats a concern, perhaps you would consider just targeting f39 and > for f38 just doing test days and reminders asking developers to test > instead of changing it and then changing it back? > > > > > Before f38 beta freeze, change owners/fesco looks at the state of things > > > and decides if it can remain on in f38 and if not, it gets reverted and > > > moved to f39. > > > > Not sure how it's better than reverting in branched f38 but not rawhide, > > unless the goal is to hasten the change. > > It's better because it seems more direct and honest to me. > It means you are landing a change and trying to get it done, not landing > it to break people and then at the last minute after people rush to fix > things, removing it again. I also suspect there will be some feet > dragging due to this: "Oh, it's broken now, but they are going to revert > it anyhow, so I won't do anything". If this helps, from the perspective of tracking rawhide, we flip the switch and don't revert it. So the "they'll revert it" argument doesn't work at least for rawhide. > > > In the run up to f38 beta we could: > > > > > > * run a series of test days. perhaps one before you enable it in > > > rawhide, one a month or two later and one right before f38 beta > > > freeze? > > > > I'm for more test days. > > There was one held already and I'm open for holding more in the future. > > Plus I should attempt some side-tag mass-rebuild or equivalent, > > but I, unfortunately, won't get to it until October at the earliest. > > Sure, understand time is low for everyone. ;( > > > > * see if openqa might have some way to set TEST-FEDORA39 and re-run > > > tests on a compose or updates? This might be a good thing to try and do > > > before landing it in rawhide. > > > > Sounds great if that's a possibility, but I don't know how to approach it. > > Perhaps Adam can chime in here... > > > > * setup a tracking bug to track the issues, so we can make a more > > > informed decision before f38 beta. > > > > > > Thoughts? > > > > If the core of your proposal is > > * make it happen in f38 and revert and push back to f39 only if necessary > > as opposed to > > * make it happen in f38 rawhide, f39 rawhide, f39 branched and released, > > but not f38 branched (the current proposal) > > then I can't say I understand what you are trying to achieve with > > that. > > I don't care for "Here's a change, adjust to it please! Hurry!" Oh, just > kidding, it will not take effect until next cycle. That just seems to be > dishonest to our users. > > > IMO it makes the switch less certain, more frantic and more abrupt, > > while I was trying to smoothen it out in time as far as possible. > > I don't think it's possible to cleanly spread out a change like this > over more than 1 long fedora cycle. That's a reason why my initial thread [1] has been named "Landing a larger-than-release change (distrusting SHA-1 signatures)": flipping the switch is the easy part, unfortunately. > > So +1 on all the accompanying activities possible, > > -1 on expediting the switch. > > ok. I'm not sure where the rest of fesco is on this, but I guess we will > see. :) > > Thanks for listening. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi wrote: > > How about this: > > Drop the term 'jump scare' entirely. IMHO it just sounds bad. I'm open for proposals on the wording. =) > Rework the change so it's basically planning on making this change in > f38. That makes it closer than currently, defeating the purpose of letting people prepare. > Before f38 beta freeze, change owners/fesco looks at the state of things > and decides if it can remain on in f38 and if not, it gets reverted and > moved to f39. Not sure how it's better than reverting in branched f38 but not rawhide, unless the goal is to hasten the change. > In the run up to f38 beta we could: > > * run a series of test days. perhaps one before you enable it in > rawhide, one a month or two later and one right before f38 beta > freeze? I'm for more test days. There was one held already and I'm open for holding more in the future. Plus I should attempt some side-tag mass-rebuild or equivalent, but I, unfortunately, won't get to it until October at the earliest. > * see if openqa might have some way to set TEST-FEDORA39 and re-run > tests on a compose or updates? This might be a good thing to try and do > before landing it in rawhide. Sounds great if that's a possibility, but I don't know how to approach it. > * setup a tracking bug to track the issues, so we can make a more > informed decision before f38 beta. > > Thoughts? If the core of your proposal is * make it happen in f38 and revert and push back to f39 only if necessary as opposed to * make it happen in f38 rawhide, f39 rawhide, f39 branched and released, but not f38 branched (the current proposal) then I can't say I understand what you are trying to achieve with that. IMO it makes the switch less certain, more frantic and more abrupt, while I was trying to smoothen it out in time as far as possible. So +1 on all the accompanying activities possible, -1 on expediting the switch. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpm with sequoia pgp
On Mon, Sep 5, 2022 at 10:55 AM Fabio Valentini wrote: > > On Mon, Sep 5, 2022 at 10:12 AM Alexander Sosedkin > wrote: > > > > Quoting Neal H. Walfield (2022-09-02 16:31:18) > > > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on > > > Sequoia PGP. > > > > > > https://rpm.org/wiki/Releases/4.18.0 > > > https://sequoia-pgp.org/ > > > > > > Thanks to Fabio Valentini (decathorpe) for packaging not only > > > rpm-sequoia, but all of the Sequoia packages for Fedora. > > > > > > > > > https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/ > > > > > > > > > With this note, I'd firstly like to make the Fedora community more > > > aware of this project. (I don't think it has been mentioned here > > > yet.) > > > > > > Second, although the internal OpenPGP backend is still the default > > > backend, it will be removed in rpm 4.19: > > > > > > https://github.com/rpm-software-management/rpm/issues/1935 > > > > > > It is probably best to start the transition as soon as possible to > > > work out any kinks. > > > > > > In that vein, I'd like to offer my help. Making this type of change > > > needs to be done carefully. Perhaps these are questions or concerns. > > > I'd like to hear them and respond to them. There is also technical > > > work that needs to be done. I'm more of a developer than a packager, > > > but if Fedora decides to use the Sequoia backend, I'd like to offer my > > > help in any way I can. > > > > > > > > > > > > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing > > > work to port it to Sequoia to OpenSSL: > > > > > > > > > https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 > > > > Mind the > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies > > > > Will we need to introduce a configuration mechanism to limit algorithm > > selection in Sequoia PGP? Or just wait untl it switches to OpenSSL? > > Isn't this handled at the level of the crypto library? That's my question, really: does it need extra configuration generated or will it just attempt a low-level library operation and fail gracefully when it finds the operations blocked? > OpenPGP uses nettle for cryptography purposes, shouldn't *that* follow > system crypto policy, just as OpenSSL does? > For example, I don't see anything related to crypto policies in the > gnupg2 package, either. Unfortunately, nettle and gnupg2 don't follow crypto-policies (yet?). It's only beginning to expand beyond networking protocols (TLS/SSH/KRB...). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpm with sequoia pgp
Quoting Neal H. Walfield (2022-09-02 16:31:18) > rpm 4.18 is on the horizon and includes a new OpenPGP backend based on > Sequoia PGP. > > https://rpm.org/wiki/Releases/4.18.0 > https://sequoia-pgp.org/ > > Thanks to Fabio Valentini (decathorpe) for packaging not only > rpm-sequoia, but all of the Sequoia packages for Fedora. > > > https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/ > > > With this note, I'd firstly like to make the Fedora community more > aware of this project. (I don't think it has been mentioned here > yet.) > > Second, although the internal OpenPGP backend is still the default > backend, it will be removed in rpm 4.19: > > https://github.com/rpm-software-management/rpm/issues/1935 > > It is probably best to start the transition as soon as possible to > work out any kinks. > > In that vein, I'd like to offer my help. Making this type of change > needs to be done carefully. Perhaps these are questions or concerns. > I'd like to hear them and respond to them. There is also technical > work that needs to be done. I'm more of a developer than a packager, > but if Fedora decides to use the Sequoia backend, I'd like to offer my > help in any way I can. > > > > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing > work to port it to Sequoia to OpenSSL: > > > https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 Mind the https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies Will we need to introduce a configuration mechanism to limit algorithm selection in Sequoia PGP? Or just wait untl it switches to OpenSSL? > ... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
On Mon, Aug 29, 2022 at 10:48 PM Miro Hrončok wrote:
>
> On 29. 08. 22 20:30, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2
> >
> > == Summary ==
> >
> > Cryptographic policies will be tightened in Fedora ''38''-39,
> > SHA-1 signatures will no longer be trusted by default.
> > Fedora ''38'' will do a "jump scare", introducing the change but then
> > reverting it in time for Beta.
> > Test your setup with TEST-FEDORA39 today and file bugs in advance so
> > you won't get bit by Fedora ''38''-39.
>
> It is my opinion that breaking things on purpose ("jump scaring") is not a
> friendly way of making things happen. Sure, when other options are exhausted,
> let's consider it as an extreme option, but maybe we can figure something else
> out first.
>
> Have you for example considered:
>
> - changing the default in Copr and rebuilding the distro, seeing what
> breaks?
That's in my plans, but it won't catch user-important scenarios
not covered by tests of other packages.
> - changing the default in ELN only first?
That's already done.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedocal] Reminder meeting : ELN SIG
On Fri, Aug 26, 2022 at 5:09 PM Stephen Gallagher wrote: > On Fri, Aug 26, 2022 at 10:12 AM Alexander Sosedkin > wrote: > > On Fri, Aug 26, 2022 at 4:06 PM Troy Dawson wrote: > > > On Fri, Aug 26, 2022 at 6:55 AM Alexander Sosedkin > > > wrote: > > >> Not a full-blown meeting prompt, > > >> but I recall complaining about `fipscheck` missing from ELN repositories, > > >> and IIRC it was blocked on something that time. > > >> If you could have a second look, that'd be appreciated, > > >> as it's a popular build dependency among the packages I'm concerned > > >> about. > > > > > > > > > is `fipscheck` = libkcapi-fipscheck ? > > > If so, it's built and in ELN. > > > It did have a failed build in July, but it's been rebuilding fine since > > > July 27. > > > > I can't find it under > > https://odcs.fedoraproject.org/composes/production/latest-Fedora-ELN/ > > https://tiny.distro.builders/view-srpm--view-eln--libkcapi.html has it > listed as part of the buildroot, but it's not specifically included in > the ELN compose. The same is true for CentOS Stream 9[1] and RHEL 9, > so if this is incorrect it should be resolved there and we will pull > it in. Otherwise, it remains available in the Koji buildroot, Is there a repository URL I can readily use to enable this Koji buildroot on an ELN system? > but won't show up in the ELN compose. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedocal] Reminder meeting : ELN SIG
On Fri, Aug 26, 2022 at 4:06 PM Troy Dawson wrote: > On Fri, Aug 26, 2022 at 6:55 AM Alexander Sosedkin > wrote: >> Not a full-blown meeting prompt, >> but I recall complaining about `fipscheck` missing from ELN repositories, >> and IIRC it was blocked on something that time. >> If you could have a second look, that'd be appreciated, >> as it's a popular build dependency among the packages I'm concerned about. > > > is `fipscheck` = libkcapi-fipscheck ? > If so, it's built and in ELN. > It did have a failed build in July, but it's been rebuilding fine since July > 27. I can't find it under https://odcs.fedoraproject.org/composes/production/latest-Fedora-ELN/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedocal] Reminder meeting : ELN SIG
On Fri, Aug 26, 2022 at 2:54 PM Stephen Gallagher wrote: > > On Thu, Aug 25, 2022 at 8:00 AM wrote: > > > > Dear all, > > > > You are kindly invited to the meeting: > >ELN SIG on 2022-08-26 from 12:00:00 to 13:00:00 US/Eastern > >At fedora-meet...@irc.libera.chat > > > > The meeting will be about: > > We have no agenda for today's meeting. If anyone has a topic to bring > up, please reply to this email. Otherwise, the meeting will be > canceled for this week. Not a full-blown meeting prompt, but I recall complaining about `fipscheck` missing from ELN repositories, and IIRC it was blocked on something that time. If you could have a second look, that'd be appreciated, as it's a popular build dependency among the packages I'm concerned about. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby FTBFS due to "SHA-1 jump scare"
On Wed, Aug 24, 2022 at 4:33 PM Alexander Sosedkin wrote: > > On Wed, Aug 24, 2022 at 4:32 PM Fabio Valentini wrote: > > > > On Wed, Aug 24, 2022 at 4:28 PM Alexander Sosedkin > > wrote: > > > > > > On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch wrote: > > > > > > > > Alexander, > > > > > > > > Would you mind to comment on your intentions with: > > > > > > > > https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide > > > > > > > > which just landed in Fedora and broke Ruby test suite (even more then it > > > > was broken before): > > > > > > > > https://koschei.fedoraproject.org/package/ruby > > > > > > > > Although I know something like this was discussed and is already enabled > > > > in c9s, > > > > > > Yes, it was: [2], [3] > > > > > > > I am not aware that the associated change [1] would be approved > > > > nor that you would send a warning that this is going to happen. > > > > > > Wait, right. It was just the Forewarning1 [4] that was approved, > > > not the Forewarning2 one. > > > > > > > Am I missing something? > > > > > > My intention was to break it right at the branch-off. > > > What do I do now? Just keep it as it is? > > > Revert, somehow initiate the approval early and unrevert once I have one? > > > > I don't think keeping rawhide/f38 intentionally broken, even if you're > > going to revert the brokenness in f38 after it branches off, is ever a > > good idea. > > Please revert the change and wait for the devel list and FESCo > > discussion of the topic before implementing it again. > > Ack, will do promptly. My bad. Reverted in crypto-policies-20220824-2.git2187e9c.fc38, sorry for the premature jump scare. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby FTBFS due to "SHA-1 jump scare"
On Wed, Aug 24, 2022 at 4:32 PM Fabio Valentini wrote: > > On Wed, Aug 24, 2022 at 4:28 PM Alexander Sosedkin > wrote: > > > > On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch wrote: > > > > > > Alexander, > > > > > > Would you mind to comment on your intentions with: > > > > > > https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide > > > > > > which just landed in Fedora and broke Ruby test suite (even more then it > > > was broken before): > > > > > > https://koschei.fedoraproject.org/package/ruby > > > > > > Although I know something like this was discussed and is already enabled > > > in c9s, > > > > Yes, it was: [2], [3] > > > > > I am not aware that the associated change [1] would be approved > > > nor that you would send a warning that this is going to happen. > > > > Wait, right. It was just the Forewarning1 [4] that was approved, > > not the Forewarning2 one. > > > > > Am I missing something? > > > > My intention was to break it right at the branch-off. > > What do I do now? Just keep it as it is? > > Revert, somehow initiate the approval early and unrevert once I have one? > > I don't think keeping rawhide/f38 intentionally broken, even if you're > going to revert the brokenness in f38 after it branches off, is ever a > good idea. > Please revert the change and wait for the devel list and FESCo > discussion of the topic before implementing it again. Ack, will do promptly. My bad. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ruby FTBFS due to "SHA-1 jump scare"
On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch wrote: > > Alexander, > > Would you mind to comment on your intentions with: > > https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide > > which just landed in Fedora and broke Ruby test suite (even more then it > was broken before): > > https://koschei.fedoraproject.org/package/ruby > > Although I know something like this was discussed and is already enabled > in c9s, Yes, it was: [2], [3] > I am not aware that the associated change [1] would be approved > nor that you would send a warning that this is going to happen. Wait, right. It was just the Forewarning1 [4] that was approved, not the Forewarning2 one. > Am I missing something? My intention was to break it right at the branch-off. What do I do now? Just keep it as it is? Revert, somehow initiate the approval early and unrevert once I have one? > [1] https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2 [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/ [3] https://lwn.net/Articles/887832/ [4] https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning1 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: ca-certificates latest updates and Mozilla NSS certdata.txt modifications
On Thu, Aug 18, 2022 at 1:45 PM Yann Droneaud wrote: > I've noticed ca-certificates package was updated recently, and went looking > at the changes, and I have some questions. Not Bob Relyea, but I'll try to answer to the best of my knowledge: > The first issue is what certdata.txt was used ? It's supposed to be > downloaded from Mozilla NSS sources, but doesn't match any released > versions. 3.79, as suggested by both the changelog entries and https://src.fedoraproject.org/rpms/ca-certificates/blob/rawhide/f/nssckbi.h matching https://hg.mozilla.org/projects/nss/raw-file/NSS_3_79_RTM/lib/ckfw/builtins/nssckbi.h > The second issue is what are the changes that were made to certdata.txt ? > The commit messages and RPM changelogs say the root CA certificate database > was updated thrice to the same version. > > Below the 3 latest updates to certdata.txt used to build the root CA > certificates database in ca-certificates RPM package for Fedora Rawhide > from ca-certificates git repository > ... > As you can find, the last 3 ca-certificate's certdata.txt version match > *no* NSS's certdata.txt which is suspicious. > > In https://fedoraproject.org/wiki/CA-Certificates it is said, that since > Fedora 25, there's no modification on the upstream root certificates > database. So what happened here ? > > Unfortunately, the ca-certificates' commit messages nor the RPM's changelog > provide any reason for the differences. > > This raise the question of the trust we can have in the update, if the > certdata.txt supposedly imported from Mozilla NSS, doesn't match any file > released by Mozilla. Indeed it doesn't. If you diff it against Mozilla's https://hg.mozilla.org/projects/nss/log/NSS_3_79_RTM/lib/ckfw/builtins/certdata.txt you should observe significant differences of two varieties: 1. -CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_MUST_VERIFY_TRUST +CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_TRUSTED_DELEGATOR on some of the Mozilla-originating certificates 2. half of the file consisting of newly added certificates with a comment # Microsoft Code Signing Only Certificate trusted for code signing alone. diff -U0 upstream-3.79.txt certdata-fedora.txt | grep CKA_TRUST | sort -u +CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_TRUSTED_DELEGATOR +CKA_TRUST_EMAIL_PROTECTION CK_TRUST CKT_NSS_MUST_VERIFY_TRUST +CKA_TRUST_SERVER_AUTH CK_TRUST CKT_NSS_MUST_VERIFY_TRUST +CKA_TRUST_STEP_UP_APPROVED CK_BBOOL CK_FALSE -CKA_TRUST_CODE_SIGNING CK_TRUST CKT_NSS_MUST_VERIFY_TRUST Thus, for purposes other than code signing we have effectively Mozilla's 3.79 version. For code signing, we additionally trust an extra set of certificates, including ones not coming from Mozilla. The rather detailed description in https://bugzilla.redhat.com/show_bug.cgi?id=2117793 suggests that this is an unfortunately non-transparent stop-gap solution of sorts to satisfy .NET code signing needs while a better approach is in the works. > Commit messages (and RPM changelog) should details the changes made to the > NSS's certdata.txt during the update. And, for the sake of traceability, the > repository, branch, tag, hg commit, from which certdata.txt was pulled > should > also be part of the commit message (and RPM changelog). (and an empty line > between commit title and the rest of the commit message would be > appreciated, > for git log --oneline usage). That'd be great. > It should also be noted the fetch.sh script (most notably check_certs.sh) is > doing a terrible job at reporting the changes, most notably saying already > present certificates are added. I'd also like to suggest separating Mozilla and Microsoft-originating certdata in the repository and only mixing them together as part of the build process, if need be. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam
Quoting Kevin Kofler via devel (2022-06-30 14:15:04) > You are making two doubtful assumptions: > > 1. That the users will bother reporting their issues to the server > administrators at all. I would expect them to just blame Fedora for it and > move to a different operating system that just works, or at most to apply a > local workaround (what I called "jump through hoops", e.g., changing the > system crypto policy to LEGACY and/or loading the legacy provider with its > legacy algorithms into OpenSSL) and then forget about it. > 2. That the server administrators will actually care about complaints from > non-Windows users, assuming they even read user complaints at all to begin > with, and that they will be willing to switch to newer (more secure) > algorithms that may break compatibility with some ancient operating systems > that other users might still use. I agree with your statements but I do not make the assumptions you prescribe to me. I'm painfully aware that progress doesn't happen magically when we break something in Fedora. Hoops are a horrible propellant of progress, but still the best one we have. > I do not believe that Fedora actually has any levy to get server > administrators to upgrade their setups. > We have to work with whatever obsolete junk is out there. Is Fedora supposed to be a locomotive of secure defaults? In an attempt to slow down devolving into opinion-vs-opinion, let me back mine with https://docs.fedoraproject.org/en-US/project: > Four Foundations: First > > We are committed to innovation. > > We are not content to let others do all the heavy lifting on our behalf; > we provide the latest in stable and robust, useful, > and powerful free software in our Fedora distribution. > > At any point in time, the latest Fedora platform > shows the future direction of the operating system > as it is experienced by everyone from the home desktop user > to the enterprise business customer. > Our rapid release cycle > is a major enabling factor in our ability to innovate. > > We recognize that there is also a place for long-term stability in the > Linux ecosystem, and that there are a variety of community-oriented > and business-oriented Linux distributions available to serve that need. > However, the Fedora Project’s goal of advancing free software dictates > that the Fedora Project itself pursue a strategy > that preserves the forward momentum of our technical, > collateral, and community-building progress. > Fedora always aims to provide the future, first. In terms of cryptographic defaults, Fedora even lags behind RHEL, so requests to slow down even further don't elicit much support from me. If one day this page replaces "First" with, say, "Compatibility: we have to work with whatever obsolete junk is out there, security comes second", I will concede. But today, I think the current pace of deprecations *in the default configuration* doesn't just align with Fedora's goals, it's slower than it should be. Non-default configurations are a different beast altogether, and the users' feet-shooting freedom is something we should defend, yes. But the defaults have to march on unabated. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: help needed on AskFedora: OpenSSLv3 error when connecting to Eduroam
Quoting Kevin Kofler via devel (2022-06-30 13:16:55) > Clemens Lang wrote: > > I hope you’re not suggesting we keep the defaults insecure because there > > are some institutions out there that don’t support modern standards. > > Sorry, but I am. > The defaults need to work out there in the real world. Your model lacks the driver for deprecating anything for good, in neither defaults nor the real world. > If legacy standards are still widespread, > they need to be supported out of the box, Yes. > without having to jump through hoops. No, or nothing ever moves on, squarely because > Users want to be able to connect to their WPA* WiFi networks, > view their HTTPS websites, etc. > They do not care whether those use the latest, > most secure versions of the standard or not. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package proposal: google-drive-ocamlfuse
Quoting Marián Konček (2022-06-29 10:26:13) > I recently discovered this project: > https://github.com/astrada/google-drive-ocamlfuse > > Supposedly it makes it possible to mount google drive as a filesystem > using fuse. Not to devalue the request, but this requirement alone should be covered by an already packaged rclone (https://rclone.org). > I wanted to try to package it myself, but ocaml seems a bit esoteric and > we are currently missing at least 5 dependencies in Fedora. > > Nevertheless I think this package would be useful for many people. > > Would anyone (perhaps someone who maintains other ocaml packages) be > willing to package this? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Firefox/nss behaviour change in F36?
On Mon, Jun 6, 2022 at 12:03 PM Bojan Smojver via devel wrote: > > Before I open a bug on this, the latest firefox/nss software that is in F36 - > is it not accepting SSL certificates without matching subjectAlternativeName > on purpose? > > I still have to complete more tests, but it seems that if SSL certificate is > issued to CN abc.example.com and if that name is not mentioned in SAN, > Firefox complains that the certificate is not for the right domain. This is > all only with most recent updates. > > Anyone else seeing similar stuff? https://www.mozilla.org/en-US/firefox/101.0/releasenotes says: > Removed "subject common name" fallback support from certificate validation. > This fallback mode was previously enabled > only for manually installed certificates. > The CA Browser Forum Baseline Requirements > have required the presence of the "subjectAltName" extension since 2012, > and use of the subject common name was deprecated in RFC 2818. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
On Tue, May 31, 2022 at 4:09 PM Petr Pisar wrote: > > V Tue, May 31, 2022 at 03:51:26PM +0200, Alexander Sosedkin napsal(a): > > On Tue, May 31, 2022 at 3:45 PM Petr Pisar wrote: > > > > > > V Tue, May 31, 2022 at 02:56:56PM +0200, Alexander Sosedkin napsal(a): > > > > On Tue, May 31, 2022 at 12:28 PM Vitaly Zaitsev via devel > > > > wrote: > > > > > On 31/05/2022 10:21, Petr Pisar wrote: > > > > > > Not in current F37 FUTURE policy the user tested. > > > > > > > > > > Yes. If the new F37 cryptographic policy considers RSA-2048 to be > > > > > weak, > > > > > it should be reverted. > > > > > > > > The actual proposal is in the OP. > > > > > > > > Not only there's no such thing as "new F37 policy" happening, > > > > the F39 DEFAULT does allow RSA-2048, > > > > and this is spelled out upfront in the proposal text in the OP. > > > > RSA-3072 is only the minimum for the opt-in FUTURE policy, > > > > which has been the case since at least F28. > > > > > > > I'm sorry. You are right that the key length limit won't change. > > > > > > Probably what confused us is this sentence: > > > > > > Test your setup with FUTURE today and file bugs so you won't get bit > > > by > > > Fedora 38-39. > > > > > > That's obviously incorect because current FUTURE is not equvialent to the > > > proposed DEFAULT. I recommend you to reword the testing procedure so that > > > people are not bitten by this discrepancy. > > > > > > Maybe you should prepare a policy DEFAULT-F39, package it into current > > > Fedora, > > > and ask people to test DEFAULT-F39 instead of FUTURE or FUTURE:SHA1. > > > > That'd be TEST-FEDORA39, mentioned as an alternative in the same sentence: > > > > > Install crypto-policies-scripts package and switch to a more restrictive > > > policy > > > with either update-crypto-policies --set FUTURE or update-crypto-policies > > > --set TEST-FEDORA39. > > > > I chose to suggest them in this particular order > > in hopes of bringing the world a tad closer to the FUTURE and not just > > F39 DEFAULT. > > > > Should I drop it? > > That would be great. If this change is about SHA-1, I would only keep > TEST-FEDORA39 in the Change page. > > If you want to promote FUTURE, you can keep a small notice at the end of How > To Test section that people who want to sense security of far future, can try > FUTURE policy. But make sure that it's written in an obvious way that FUTURE > is out of scope of this Change. Fair. Deprioritized testing FUTURE, warned that it's not gonna become defaults and made TEST-FEDORA39 more prominent: https://fedoraproject.org/w/index.php?title=Changes%2FStrongCryptoSettings3Forewarning1=revision=646390=646384 https://fedoraproject.org/w/index.php?title=Changes%2FStrongCryptoSettings3Forewarning2=revision=646391=646385 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
On Tue, May 31, 2022 at 3:45 PM Petr Pisar wrote: > > V Tue, May 31, 2022 at 02:56:56PM +0200, Alexander Sosedkin napsal(a): > > On Tue, May 31, 2022 at 12:28 PM Vitaly Zaitsev via devel > > wrote: > > > On 31/05/2022 10:21, Petr Pisar wrote: > > > > Not in current F37 FUTURE policy the user tested. > > > > > > Yes. If the new F37 cryptographic policy considers RSA-2048 to be weak, > > > it should be reverted. > > > > The actual proposal is in the OP. > > > > Not only there's no such thing as "new F37 policy" happening, > > the F39 DEFAULT does allow RSA-2048, > > and this is spelled out upfront in the proposal text in the OP. > > RSA-3072 is only the minimum for the opt-in FUTURE policy, > > which has been the case since at least F28. > > > I'm sorry. You are right that the key length limit won't change. > > Probably what confused us is this sentence: > > Test your setup with FUTURE today and file bugs so you won't get bit by > Fedora 38-39. > > That's obviously incorect because current FUTURE is not equvialent to the > proposed DEFAULT. I recommend you to reword the testing procedure so that > people are not bitten by this discrepancy. > > Maybe you should prepare a policy DEFAULT-F39, package it into current Fedora, > and ask people to test DEFAULT-F39 instead of FUTURE or FUTURE:SHA1. That'd be TEST-FEDORA39, mentioned as an alternative in the same sentence: > Install crypto-policies-scripts package and switch to a more restrictive > policy > with either update-crypto-policies --set FUTURE or update-crypto-policies > --set TEST-FEDORA39. I chose to suggest them in this particular order in hopes of bringing the world a tad closer to the FUTURE and not just F39 DEFAULT. Should I drop it? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
On Tue, May 31, 2022 at 12:28 PM Vitaly Zaitsev via devel wrote: > On 31/05/2022 10:21, Petr Pisar wrote: > > Not in current F37 FUTURE policy the user tested. > > Yes. If the new F37 cryptographic policy considers RSA-2048 to be weak, > it should be reverted. The actual proposal is in the OP. Not only there's no such thing as "new F37 policy" happening, the F39 DEFAULT does allow RSA-2048, and this is spelled out upfront in the proposal text in the OP. RSA-3072 is only the minimum for the opt-in FUTURE policy, which has been the case since at least F28. > Many servers still use RSA-2048 (the default in Let's Encrypt). And that's why it is going to be accepted in DEFAULT even in F39+. Please tone down the FUD, your signal/noise ratio has been record low over the last few weeks, with statements being technically true and most of the time agreeable, yet inexplicably resulting in a net negative benefit to the discussion. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
On Mon, May 30, 2022 at 10:34 PM Garry T. Williams wrote: > > On Friday, April 29, 2022 5:49:05 PM EDT Ben Cotton wrote: > > Cryptographic policies will be tightened in Fedora 38-39, > > SHA-1 signatures will no longer be trusted by default. > > Fedora 37 specifically doesn't come with any change of defaults, > > and this Fedora Change is an advance warning filed for extra visibility. > > Test your setup with FUTURE today and file bugs so you won't get bit > > by Fedora 38-39. > > [snip] > > In case you want some feedback, Thank you for taking time to do that. > > Install crypto-policies-scripts package and switch to a more restrictive > > policy > > with either `update-crypto-policies --set FUTURE` > > or `update-crypto-policies --set TEST-FEDORA39`. > > > > Proceed to use the system as usual, > > identify the workflows which are broken by this change. > > I did that and several days later I did: > > $ sudo dnf upgrade --enablerepo=updates-testing > Errors during downloading metadata for repository 'fedora': > - Curl error (60): SSL peer certificate or SSH remote key was not OK > for > https://mirrors.fedoraproject.org/metalink?repo=fedora-36=x86_64=3 > [SSL certificate problem: CA certificate key too weak] > - Curl error (60): SSL peer certificate or SSH remote key was not OK > for https://mirrors.fedoraproject.org/metalink?repo=fedora-36=x86_64 > [SSL certificate problem: CA certificate key too weak] > Error: Failed to download metadata for repo 'fedora': Cannot prepare > internal mirrorlist: Curl error (60): SSL peer certificate or SSH remote key > was not OK for > https://mirrors.fedoraproject.org/metalink?repo=fedora-36=x86_64 [SSL > certificate problem: CA certificate key too weak] > > > Verify that the broken functionality works again > > if you the policy is relaxed back > > with, e.g., `update-crypto-policies --set FUTURE:SHA-1`, > > This was a problem: > > $ sudo update-crypto-policies --set FUTURE:SHA-1 > Unknown policy `SHA-1`: file `SHA-1.pmod` not found in (., > policies/modules, /etc/crypto-policies/policies/modules, > /usr/share/crypto-policies/policies/modules) > > That seems like a typo. Indeed, thanks for spotting. Fixed in two places. > After looking in > /usr/share/crypto-policies/policies/modules, I tried again with: > > $ sudo update-crypto-policies --set FUTURE:SHA1 > Setting system policy to FUTURE:SHA1 > > But that didn't get me back. I got the same error doing dnf upgrade. > > I had to do: > > $ sudo update-crypto-policies --set DEFAULT > > to get back to dnf working again. > > > file bug reports against the affected components if not filed already. > > I really don't know what "component" to use filing a bug. Yeah, that seems like a case when the service administrator is the one to be notified. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Tue, May 17, 2022 at 5:09 PM Daniel P. Berrangé wrote: > > On Tue, May 17, 2022 at 04:20:56PM +0200, Tomasz Torcz wrote: > > On Tue, May 17, 2022 at 02:11:03PM +0200, Vitaly Zaitsev via devel wrote: > > > > First - our burden. We ahve to certify each binary. This is quite long > > > > and lenghty process. Onl once it is certified, we can release it (with > > > > small unwritten exception in rawhide) > > > > > > Just stop doing TCK certification. Most of Fedora users don't need > > > "certified binaries". > > > > Exactly. This change does not benefit Fedora, it is only to make > > certification easier. Certification which is not needed. > > At its heart the certification is a "sticker" that asserts our > JDK has passed the TCK test suite. IOW, saying that we don't need > certification of JDK is effectively saying that we don't need to do > testing of JDK in Fedora. Correct me if I'm wrong in that specific case, but, purely logically, "certification implies some testing" doesn't imply "lack of certification abolishes all testing". > Comprehensive testing of software is > something that very much does benefit Fedora and its users, and we > could do with a whole lot more of it in general. Further elsewhere > in this thread it has been clearly said that users of JDKs do > indeed value the certification as a sign of quality. So I don't > think we can credibly claim that certification is not needed. > > The challenege is how to make the certification managable for the > maintainers, while also having the packaging process be amenable > to Fedora processes. Eliminating testing of JDK is not a desirable > solution. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
On Wed, May 4, 2022 at 12:52 PM Vít Ondruch wrote: > > Dne 04. 05. 22 v 9:32 Alexander Sosedkin napsal(a): > > On Wed, May 4, 2022 at 12:43 AM David Woodhouse wrote: > >> On Mon, 2022-05-02 at 19:33 +0200, Clemens Lang wrote: > >>> This is the reason why the proposal contains extensive methods to test > >>> whether things are going to break by modifying the crypto-policy or using > >>> bpftrace. Unfortunately there are hundreds of packages that depend on > >>> cryptographic libraries, and millions of different configurations out > >>> there. > >>> We can’t know ahead of time which ones of them are going to break, but the > >>> proposal provides tools and a long transition period to identify and fix > >>> them. > >> When changes like this broke things for users in the past, we talked > >> about a way to present the "insufficient crypto/digest/protocol" as > >> just another failure like server certificate validation failures, so > >> the application/user can *choose* to accept and proceed, in real time. > >> > >> I'd like to see that as a *condition* of acceptance of further > >> restrictions in the policy. > >> > >> I really don't want us continuing to break things for Fedora users and > >> driving them back to the proprietary VPN clients. > >> > >> I am pleased to see some progress on this front with > >> https://fedoraproject.org/wiki/Changes/GnutlsAllowlisting but it isn't > >> clear to me that this gives us what we need. We *want* to warn users > >> that their VPN server doesn't meet modern crypto standards. We don't > >> want to just blindly re-enable ancient crap and have it silently work. > >> But we also do *need* it to work, after we've warned the user about it. > > If the error returned from GnuTLS isn't enough to infer > > > While I don't know much about GnuTLS, I have yet to see single OpenSSL > error message which would help user to understand the issue. I was talking error codes, not error messages, but oof. > > that you should make the user opt-in into a legacy algorithm > > and then counter the restriction on the next attempt with > > a priority string extension or gnutls_protocol_mark_enabled, > > please file a bug with GnuTLS and describe your case. > > Your continued input would be appreciated. > > Same with the other libraries if you meant other libraries. > > > > If you don't want to spend a connection on just probing, > > but instead prefer to connect no matter what > > and then query what has been negotiated > > to make the warn/abort decisions on the application layer > > that should also be possible. > > > >> Which is why handling it like a certificate validation failure seems to > >> be the right answer, but I'm happy to explore other solutions... but > >> preferably *not* solutions like "manually set > >> GNUTLS_SYSTEM_PRIORTY_FILE=/dev/null in your Fedora package to > >> explicitly override all the Fedora crypto policies". That suggestion > >> made me sad... :) > > +1, this is not the way ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
On Wed, May 4, 2022 at 12:43 AM David Woodhouse wrote: > > On Mon, 2022-05-02 at 19:33 +0200, Clemens Lang wrote: > > This is the reason why the proposal contains extensive methods to test > > whether things are going to break by modifying the crypto-policy or using > > bpftrace. Unfortunately there are hundreds of packages that depend on > > cryptographic libraries, and millions of different configurations out there. > > We can’t know ahead of time which ones of them are going to break, but the > > proposal provides tools and a long transition period to identify and fix > > them. > > When changes like this broke things for users in the past, we talked > about a way to present the "insufficient crypto/digest/protocol" as > just another failure like server certificate validation failures, so > the application/user can *choose* to accept and proceed, in real time. > > I'd like to see that as a *condition* of acceptance of further > restrictions in the policy. > > I really don't want us continuing to break things for Fedora users and > driving them back to the proprietary VPN clients. > > I am pleased to see some progress on this front with > https://fedoraproject.org/wiki/Changes/GnutlsAllowlisting but it isn't > clear to me that this gives us what we need. We *want* to warn users > that their VPN server doesn't meet modern crypto standards. We don't > want to just blindly re-enable ancient crap and have it silently work. > But we also do *need* it to work, after we've warned the user about it. If the error returned from GnuTLS isn't enough to infer that you should make the user opt-in into a legacy algorithm and then counter the restriction on the next attempt with a priority string extension or gnutls_protocol_mark_enabled, please file a bug with GnuTLS and describe your case. Your continued input would be appreciated. Same with the other libraries if you meant other libraries. If you don't want to spend a connection on just probing, but instead prefer to connect no matter what and then query what has been negotiated to make the warn/abort decisions on the application layer that should also be possible. > Which is why handling it like a certificate validation failure seems to > be the right answer, but I'm happy to explore other solutions... but > preferably *not* solutions like "manually set > GNUTLS_SYSTEM_PRIORTY_FILE=/dev/null in your Fedora package to > explicitly override all the Fedora crypto policies". That suggestion > made me sad... :) +1, this is not the way ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
On Tue, May 3, 2022 at 1:20 PM Kevin Kofler via devel wrote: > > Ian Pilcher wrote: > > It sure feels like we're reaching the point where anyone who has to work > > with any sort of older equipment or servers is going to to forced to > > switch their entire system to the LEGACY policy, which seems really > > unfortunate. > > Even worse is that even the LEGACY policy is getting stricter and stricter > (more or less silently, because it is documented only in passing as part of > the general crypto policy tightening, and the focus of the documentation is > on DEFAULT). > > I think we need a REALLY_LEGACY that continues allowing MD5 and the like. A resounding no from me. If you want one, write a custom one that's at least tailored to what exactly you want enabled. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
On Mon, May 2, 2022 at 7:18 PM Robbie Harwood wrote: > > Alexander Sosedkin writes: > > > crypto-policies' goal is to define system-wide *defaults*. > > Well, that's certainly part of it, but... > > "The purpose is to unify the crypto policies used by different > applications and libraries. That is allow setting a consistent security > level for crypto on all applications in a Fedora system, irrespective of > the crypto library in use." > > (from https://gitlab.com/redhat-crypto/fedora-crypto-policies#purpose ) > > "Unify the crypto policies used by different applications and > libraries. That is allow setting a consistent security level for crypto > on all applications in a Fedora system. The implementation approach will > be to initially modify SSL libraries to respect the policy and gradually > adding more libraries and applications." > > (from https://fedoraproject.org/wiki/Changes/CryptoPolicy#Summary ) > > So to restate: from what Nikos wrote, I read an additional goal of > unification and centralization that I don't hear echoed in what you're > saying. Unification and centralization of defaults. And yes, I can't vouch that the early crypto-policies goal was to set defaults, in fact some of the changes by Nikos set hard non-sidesteppable limits. Now we're moving away from that to setting soft-defaults. > > Cryptographic libraries already provide all kinds of finer API to > > deviate from configuration file defaults that isn't just envvars or > > pointing to configuration files; API that applications are already > > supposed to be using if they want to ensure that a specific algorithm > > is available no matter what the local/vendor/whatever configuration > > is. > > In many cases these APIs exist, but what you're proposing is a world > where applications generally need to care about their own crypto > settings. In that world, there's little incentive to use the systemwide > settings at all, and we're back to each application deciding crypto for > themselves - which doesn't strike me as appealing. Absolutely not, quite the opposite, even. I advocate for the world of applications that 1. practice cryptographic agility and trust the system defaults 2. when faced with an overly legacy scenario, fail by default 3. only if/when the operator explicitly opts to go unsafe, grant itself an exception and relax the list of what's allowed + more or less conveniently adjustable system defaults don't hurt What I tried to say is, for each and every configurable aspect of the library nobody guarantees the app author that it's allowed on a select system. Thus applications must be ready for any algorithm to be restricted and act sensibly when it is. This is the case for all distros and works the same in the crypto-policies-less world. > > The sad thing though is that it's been long limited to just TLS and > > routinely needs expansion to cover more. > > Yes, many things make the assumption that crypto == TLS. > crypto-policies already covers more than just TLS settings for > applications, so it needs to have solutions for more than just that. > > > Envvars and custom config files do exist and do function, but I don't > > consider them enough. > > So what solution do you propose that would be enough? Something akin to gnutls' recently added gnutls_sign_set_secure, we'll also need to propose something similar for OpenSSL. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
On Mon, May 2, 2022 at 6:28 PM Robbie Harwood wrote: > > JT writes: > > >> IMO, there's a rather desperate need to be able to override the > >> system-wide policy for individual processes, maybe via some sort of > >> wrapper around one of the containerization technologies. > > > > Alternatively I wouldn't be surprised if at some point the industry > > doesn't unofficially opt for a legacy openssl option which could be > > utilized by legacy code, but still allow all the modern code to use > > the new stuff. But of course if that did exist, tons of people would > > just refuse to update their code and deps because they have an option > > not to. > > While I agree that per-application policy overrides would be really > helpful, these suggested solutions are overkill. > > Concretely, crypto-policies works by managing various configuration > files. All that's needed to override on a per-application or even > per-process basis is to look at a different configuration file. > Exposing an environment variable (when it's not already) or > initialization option from the crypto library suffices for this. > > In any case, this seems like functionality best provided by > crypto-policies itself. crypto-policies' goal is to define system-wide *defaults*. Cryptographic libraries already provide all kinds of finer API to deviate from configuration file defaults that isn't just envvars or pointing to configuration files; API that applications are already supposed to be using if they want to ensure that a specific algorithm is available no matter what the local/vendor/whatever configuration is.. The sad thing though is that it's been long limited to just TLS and routinely needs expansion to cover more. Envvars and custom config files do exist and do function, but I don't consider them enough. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
On Sat, Apr 30, 2022 at 4:28 PM David Woodhouse wrote: > On Fri, 2022-04-29 at 17:49 -0400, Ben Cotton wrote: > > This document represents a proposed Change. As part of the Changes > > process, proposals are publicly announced in order to receive > > community feedback. This proposal will only be implemented if approved > > by the Fedora Engineering Steering Committee. > > > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning1 > > > > > > == Summary == > > > > Cryptographic policies will be tightened in Fedora 38-39, > > SHA-1 signatures will no longer be trusted by default. > > Fedora 37 specifically doesn't come with any change of defaults, > > and this Fedora Change is an advance warning filed for extra visibility. > > Test your setup with FUTURE today and file bugs so you won't get bit > > by Fedora 38-39. > > > > Changes like this have been very disruptive in the past because they > haven't been completely thought through. > > Can we please make 100% sure these policies are not going to break > things like VPN clients in the way that we have before. > > If you want to distrust a server SSL certificate because it's using > SHA1, that's OK. But make the crypto libraries report that just like > any *other* untrusted cert, in a way which allows the application (and > ultimately the user) to decide to accept it this time. > > The blanket refusal we had in previous iterations was awful. > > Likewise for *client* certificates. If the server issues us a > SHA1-based certificate and wants us to authenticate with it, that's the > server's problem. Making in-distro software refuse to use that client > cert just pushes uses back to using proprietary software and is overall > detrimental to our users. > > I understand there has been some progress on fixing the crypto > libraries to get this right, but I'd like FESCo to make those an > absolute condition on any further crypto pedanty in Fedora — those > things *have* to work on a per-application, user-overridable basis No arguing here... > without introducing regressions, or the Feature is reverted. ... but not sure if I understand this bit. Flipping a default and not introducing a regression is only possible if each and every impacted workflow and scenario is caught by one of the proposed testing strategies or something else. As much as I'd love to see that happen I think it's safe to say it's just not gonna happen (hence the next "jump scare" phase + 2 following cycles). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
Another status update: 1. USDT/eBPF tracing turned out to be a fruitful logging approach. Clemens Lang has kindly added USDT probes to the latest openssl builds, traceable with a small tool [1] available from a copr [2]. Yes, this way it doesn't log into your face unpromptedly, like stderr logging would, but, in turn, it's so non-invasive that we're comfortable with bringing it to Fedora 36 as well. 2. crypto-policies has added FEDORA38 and TEST-FEDORA39 policies for not following the change and testing it early correspondingly. 3. change wiki pages have been drafted for all 4 proposed rollout phases, the Fedora 36 one has been marked as ChangeReadyForWrangler. What I'd like some community help with beyond regular guidance: 1. reviews for the relevant wiki pages: https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning1 https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2 https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning3 https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3 https://fedoraproject.org/wiki/SHA1SignaturesGuidance https://fedoraproject.org/wiki/WeakCryptographyException 2. proposing the testing activities outlined there for Test Days. how is it done? [1] https://gitlab.com/redhat-crypto/fedora-sha1sig-tracer [2] https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Change proposal: make Change proposals more obvious
On Thu, Apr 28, 2022 at 3:33 PM Gary Buhrmaster wrote: > > On Wed, Apr 27, 2022 at 11:50 PM Adam Williamson > wrote: > > > Could we consider, in future, posting a clarification for journalists > > in flaming six-foot high letters (I exaggerate only slightly) at the > > top of *every* proposed Change page, and *every* official mail relating > > to a proposed Change, which clarifies that it's *proposed* not > > *accepted*, and that means it might not happen? I feel like we'd have > > to firefight less if we could do that. > > Sadly, some of this is due to the "media" organization's > need to drive page views and not journalistic ignorance > of the facts that this is just a proposal. > > I don't know how you fix the underlying revenue enhancement > approaches that have driven hyperbole and attempts to drive > engagement and outrage. And if you do, please share! > > (My cynical answer is to create a "payall" to see the > details of the proposals, with (fedora) signup and providing > detailed demographic data to complete the login (turnabout > is fair play?)). Do nothing and let them embarrass themselves freely? Their target audience is usually smart enough to see through that real quick. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
Another status update for transparency purposes: 1. openssl-3.0.2-3 and crypto-policies-20220412-1.git97fe449 now distrust SHA-1 signatures in FUTURE policy or NO-SHA1 subpolicy. Meaning that updating the packages and issuing `update-crypto-policies --set FUTURE` / `update-crypto-policies --set DEFAULT:NO-SHA1` can be used to preview the impact on Fedora 36 / 37. 2. A decision has been made for Fedora ELN to track CentOS Stream 9 crypto-policies. A side-tag rebuild has been triggered prior to the switch, and has found ELN to be in a pretty broken shape in general. Work has been temporarily stalled on that side, but I hope to get back to it. 3. I've drafted the following wiki pages so far: https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning1 https://fedoraproject.org/wiki/SHA1SignaturesGuidance https://fedoraproject.org/wiki/WeakCryptographyException feedback is welcome as usual. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On Thu, Apr 7, 2022 at 9:06 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Tue, Mar 29, 2022 at 03:34:49PM -0700, Kevin Fenzi wrote:
> > On Tue, Mar 29, 2022 at 08:12:47PM +0200, Alexander Sosedkin wrote:
> > >
> > > "You know these lights in the theaters that go out gradually?
> > > When the guy ve-ery slo-o-owly pulls the plug out?"
> > > - a joke from my childhood.
> > >
> > >
> > > Hello, it's been quiet for a while, and I've been busy
> > > but kept thinking about all the useful feedback you folks gave me.
> > > Not that it made me flesh out a perfect plan,
> > > but hopefully at least a less terrible one.
> > >
> > > Regarding smudging the change in time,
> > > how does the following three-phaser sound?
> >
> > Might work. :) A few comments inline...
> >
> > > Phase 1 ("Wake-up Call"):
> > > In Fedora 37, disable SHA-1 signatures verification/creation
> > > in FUTURE policy, i.e. opt-in only.
> > > Come up with some logging solution;
> > > I'd prefer something non-invasive like eBPF USDT probes [2],
> > > but maybe even stderr could work, you've been moderately convincing.
> > > (FUTURE change is *maybe* doable in F36, but not logging.)
> >
> > Well, we just shipped beta today, so I think it's too late to land any
> > f36 changes at this point.
> >
> > > Announce it as a system-wide change anyway for visibility,
> > > call for Test Days to report which apps/workflows rely on SHA-1
> > > signatures
> > > either from the logs
> > > or from opting into blocking operations and seeing what starts failing
> > > hard.
> > > That'd have to be very actively called for to make an impact,
> > > impact that'd mostly be just maintainers thinking what will they do in
> >
> > Just a related note here, FUTURE also breaks installing anything via dnf
> > with the default metalink setup. This is because digicert (where we get
> > our *.fedoraproject.org wildcard cert) seems to always issue certs from
> > it's 2048bit CA. :( (If anyone knows how to get them to issue from a
> > newer CA that works please let me know)
>
> This means that probably almost nobody uses FUTURE :(
>
> On Tue, Mar 29, 2022 at 08:05:00PM -0500, Michael Catanzaro wrote:
> > On Tue, Mar 29 2022 at 03:34:49 PM -0700, Kevin Fenzi
> > wrote:
> > > Well, we just shipped beta today, so I think it's too late to land any
> > > f36 changes at this point.
> >
> > This is a non-default configuration that I strongly suspect nobody or almost
> > nobody uses, except for testing. Changing this prior to F36 stable release
> > seems like no big deal.
>
> Considering that nobody uses FUTURE, I agree that we can do it for F36.
> This effectively moves everything one release forward, which is probably
> good.
I'm afraid not, because there's also a logging phase proposed,
one that shouldn't go to F36 and keeps the plan from shifting forward. Meaning:
F36: FUTURE update
F37: FUTURE update + logging
F38: DEFAULT update in rawhide only
F39: DEFAULT update that reaches release
hasn't really shortened.
> I don't think we want to drag this out *too* much.
And neither do we want to rush it.
The more ahead of the world we would be, the more work it entails for us,
so it's a balancing act.
> > > Phase 2 ("Jump Scare"):
> > > As soon as f37 branch-off happens,
> > > disable signature verification in DEFAULT in *38 rawhide*.
> > > Cue an influx of bugreports because things get broken for all testers
> > > and not just the ones who opt in.
> > > I anticipate this to be the most eye-opening step
> > > even if we test a lot in the previous phase, so to smooth it out more
> > > we then *revert* the change in 38 before the release,
> > > so the released Fedora behaves just like in 37
> > > and whatever wasn't sorted out in time gets an extra cycle.
> >
> > Right before the release?
> > Or right before Beta?
> > or ?
> >
> > People kind of expect the beta will be something they can test and will
> > behave as the final, so changing things after beta seems like a bad idea
> > in general. That said, shipping beta with it would get a lot more
> > exposure.
>
> Agreed. Any user-visible changes should be done before Beta.
>
> > > A second Fedora change should be filed for visibility,
> > > but clearly stating this will not affect f38 released.
> > >
> > > Phase 3 ("Return of the Panik"):
&
Re: [Fedocal] Reminder meeting : ELN SIG
On Thu, Apr 7, 2022 at 4:33 PM Alexander Sosedkin wrote: > > On Thu, Apr 7, 2022 at 4:11 PM Stephen Gallagher wrote: > > > > On Thu, Apr 7, 2022 at 8:52 AM wrote: > > > > > > Dear all, > > > > > > You are kindly invited to the meeting: > > >ELN SIG on 2022-04-08 from 12:00:00 to 13:00:00 US/Eastern > > >At fedora-meet...@irc.libera.chat > > > > > > The meeting will be about: > > > > I have one topic for the agenda this time around: crypto-policies in ELN > > > > For context, SHA-1 is being deprecated in RHEL for cryptographic uses > > (not for all uses). I'd like for us to carry the RHEL policies in ELN > > (currently we are using the Fedora policies). > > That's in 1.5 hours? > I'll try my best to attend but I might come a bit late (due to another > SHA-1 meeting). It was brought to my attention that it's tomorrow, sorry =) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedocal] Reminder meeting : ELN SIG
On Thu, Apr 7, 2022 at 4:11 PM Stephen Gallagher wrote: > > On Thu, Apr 7, 2022 at 8:52 AM wrote: > > > > Dear all, > > > > You are kindly invited to the meeting: > >ELN SIG on 2022-04-08 from 12:00:00 to 13:00:00 US/Eastern > >At fedora-meet...@irc.libera.chat > > > > The meeting will be about: > > I have one topic for the agenda this time around: crypto-policies in ELN > > For context, SHA-1 is being deprecated in RHEL for cryptographic uses > (not for all uses). I'd like for us to carry the RHEL policies in ELN > (currently we are using the Fedora policies). That's in 1.5 hours? I'll try my best to attend but I might come a bit late (due to another SHA-1 meeting). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On Wed, Apr 6, 2022 at 1:00 PM Vít Ondruch wrote: > > > Dne 08. 03. 22 v 19:40 Alexander Sosedkin napsal(a): > > Hello, community, I need your wisdom for planning a disruptive change. > > > > Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings > > Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 > > I believe we should start planning > > for the next cryptographic defaults tightening. > > And next time it's gonna be even more disruptive because of SHA-1 (again). > > > > SHA-1 is a hash function from 1995, > > which collision resistance is no longer to be relied upon for security [1]. > > At the same time, it's not like software has successfully migrated off it, > > not even close. > > It's not a question of "if" the world should migrate from it, > > sooner or later we must part ways with it. > > (Technically, some acute energy crisis or a collapse of civilization > > forever raising the costs of computations thousandfold would also do, > > but let's agree that migrating to a more modern hash is the way =) > > > > We've been disabling it in TLS, but its usage is much wider than TLS. > > The next agonizing step is to restrict its usage for signatures > > on the cryptographic libraries level, with openssl being the scariest one. > > > > Good news is, RHEL-9 is gonna lead the way > > and thus will take a lot of the hits first. > > > Alexander, > > Could this be enabled in ELN? This is not really question but > suggestion. It is unfortunate, that ELN, while intermediate step for c9s > does not have this enabled yet. > > For example, we are working on Ruby 3.1 for c9s [1] just to figure that > while everything just works in Fedora/ELN, it does not work in c9s. > Maybe working with ELN would make the migrations easier also for Fedora. > > > Vít It's on my plans, but it'd take some time as it's not trivial. > [1] https://gitlab.com/redhat/centos-stream/rpms/ruby/-/merge_requests/10 > > > > Fedora doesn't have to pioneer it. > > Bad news is, Fedora has to follow suit someday anyway, > > and this brings me to how does one land such a change. > > > > --- > > > > Fedora is a large distribution with short release cycles, and > > the only realistic way to weed out its reliance on SHA-1 signatures > > from all of its numerous dark corners is to break them. > > Make creation and verification fail in default configuration. > > But it's unreasonable to just wait for, say, Fedora 37 branch-off > > and break it in Rawhide for Fedora 38. > > The fallout will just be too big. > > > > Maintainers need time to get bugs, look into them, think, > > analyze, react and test --- and that's just if it fails correctly! > > Unfortunately, it's not just that the error paths are as dusty as they get > > because the program counter has never set foot on them before. > > Some maintainers might even find that > > picking a different hash function renders their code non-interoperable, > > or even that protocols they implement have SHA-1 hardcoded in the spec. > > Or that everything is ready, but real world deployments need another decade. > > Or that on-disk formats are just hard to change and migrate. > > Took git years to migrate from SHA-1, and some others haven't even started. > > There are gonna be investigations, planning, exceptions, upstream changes, > > opt-out mechanisms, arguing, compromises, waiting out, all kinds of things. > > It's gonna be big. Too big for a single release cycle. > > > > --- > > > > But how does one land something and give the distribution > > the extra cycles needed to react? That's not really clear to me. > > > > An obvious thing is to announce it in one cycle and land in another one. > > The downsides are well-documented > > in "The Hitchhiker's Guide to the Galaxy": > > announcements are one weak measure, and then it's too late. > > > > A second scheme I can come up with is a "jump scare". > > Break the functionality in Fedora 37 Rawhide, > > make most of the affected people realize the depth of the problem, > > then unbreak it. Break again for Fedora 38 and never fix. > > > > This could also be extended into "let one stable release slide'. > > Break in 37 Rawhide, unbreak on branched off 37, > > but never in Rawhide. > > > > But these are all rather... crude? > > Sure there should be better ways, > > preferably something explored before. > > I'm all for pulling this tooth out smoothly, > > but I need hints o
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On Tue, Mar 8, 2022 at 7:40 PM Alexander Sosedkin wrote:
>
> Hello, community, I need your wisdom for planning a disruptive change.
>
> Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
> Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> I believe we should start planning
> for the next cryptographic defaults tightening.
> And next time it's gonna be even more disruptive because of SHA-1 (again).
>
> SHA-1 is a hash function from 1995,
> which collision resistance is no longer to be relied upon for security [1].
> At the same time, it's not like software has successfully migrated off it,
> not even close.
> It's not a question of "if" the world should migrate from it,
> sooner or later we must part ways with it.
> (Technically, some acute energy crisis or a collapse of civilization
> forever raising the costs of computations thousandfold would also do,
> but let's agree that migrating to a more modern hash is the way =)
>
> We've been disabling it in TLS, but its usage is much wider than TLS.
> The next agonizing step is to restrict its usage for signatures
> on the cryptographic libraries level, with openssl being the scariest one.
>
> Good news is, RHEL-9 is gonna lead the way
> and thus will take a lot of the hits first.
> Fedora doesn't have to pioneer it.
> Bad news is, Fedora has to follow suit someday anyway,
> and this brings me to how does one land such a change.
>
> ---
>
> Fedora is a large distribution with short release cycles, and
> the only realistic way to weed out its reliance on SHA-1 signatures
> from all of its numerous dark corners is to break them.
> Make creation and verification fail in default configuration.
> But it's unreasonable to just wait for, say, Fedora 37 branch-off
> and break it in Rawhide for Fedora 38.
> The fallout will just be too big.
>
> Maintainers need time to get bugs, look into them, think,
> analyze, react and test --- and that's just if it fails correctly!
> Unfortunately, it's not just that the error paths are as dusty as they get
> because the program counter has never set foot on them before.
> Some maintainers might even find that
> picking a different hash function renders their code non-interoperable,
> or even that protocols they implement have SHA-1 hardcoded in the spec.
> Or that everything is ready, but real world deployments need another decade.
> Or that on-disk formats are just hard to change and migrate.
> Took git years to migrate from SHA-1, and some others haven't even started.
> There are gonna be investigations, planning, exceptions, upstream changes,
> opt-out mechanisms, arguing, compromises, waiting out, all kinds of things.
> It's gonna be big. Too big for a single release cycle.
>
> ---
>
> But how does one land something and give the distribution
> the extra cycles needed to react? That's not really clear to me.
>
> An obvious thing is to announce it in one cycle and land in another one.
> The downsides are well-documented
> in "The Hitchhiker's Guide to the Galaxy":
> announcements are one weak measure, and then it's too late.
>
> A second scheme I can come up with is a "jump scare".
> Break the functionality in Fedora 37 Rawhide,
> make most of the affected people realize the depth of the problem,
> then unbreak it. Break again for Fedora 38 and never fix.
>
> This could also be extended into "let one stable release slide'.
> Break in 37 Rawhide, unbreak on branched off 37,
> but never in Rawhide.
>
> But these are all rather... crude?
> Sure there should be better ways,
> preferably something explored before.
> I'm all for pulling this tooth out smoothly,
> but I need hints on how to do it.
> I hope that together we can devise a better plan than these.
>
> So, how does one land a change that's bigger than a release cycle?
>
> [1] https://eprint.iacr.org/2020/014
"You know these lights in the theaters that go out gradually?
When the guy ve-ery slo-o-owly pulls the plug out?"
- a joke from my childhood.
Hello, it's been quiet for a while, and I've been busy
but kept thinking about all the useful feedback you folks gave me.
Not that it made me flesh out a perfect plan,
but hopefully at least a less terrible one.
Regarding smudging the change in time,
how does the following three-phaser sound?
Phase 1 ("Wake-up Call"):
In Fedora 37, disable SHA-1 signatures verification/creation
in FUTURE policy, i.e. opt-in only.
Come up with some logging solution;
I'd prefer something non-invasive like eBPF USDT probes [2],
but maybe even stderr could work, you've been moderately convincing.
(FUTURE change is *maybe* doable in F36, but not logging.)
Announce it as a system
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On Wed, Mar 23, 2022 at 12:51 AM Josh Boyer wrote: > > On Tue, Mar 8, 2022 at 1:40 PM Alexander Sosedkin > wrote: > > > > Hello, community, I need your wisdom for planning a disruptive change. > > > > Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings > > Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 > > I believe we should start planning > > for the next cryptographic defaults tightening. > > And next time it's gonna be even more disruptive because of SHA-1 (again). > > > > SHA-1 is a hash function from 1995, > > which collision resistance is no longer to be relied upon for security [1]. > > At the same time, it's not like software has successfully migrated off it, > > not even close. > > It's not a question of "if" the world should migrate from it, > > sooner or later we must part ways with it. > > (Technically, some acute energy crisis or a collapse of civilization > > forever raising the costs of computations thousandfold would also do, > > but let's agree that migrating to a more modern hash is the way =) > > > > We've been disabling it in TLS, but its usage is much wider than TLS. > > The next agonizing step is to restrict its usage for signatures > > on the cryptographic libraries level, with openssl being the scariest one. > > > > Good news is, RHEL-9 is gonna lead the way > > and thus will take a lot of the hits first. > > Fedora doesn't have to pioneer it. > > Bad news is, Fedora has to follow suit someday anyway, > > and this brings me to how does one land such a change. > > Given that RHEL 9 already switched the crypto-policy defaults, and we > presume that future RHEL releases will not deviate from that, is this > change already made in ELN? I honestly can't tell because it looks > like it is, but I don't see any conditionalization in the spec file > that would lead me to believe the same default isn't already flipped > in Rawhide. That leaves me wondering what needs to be changed and > where at this point. > > josh No, it's neither in ELN nor in Rawhide yet. > > Fedora is a large distribution with short release cycles, and > > the only realistic way to weed out its reliance on SHA-1 signatures > > from all of its numerous dark corners is to break them. > > Make creation and verification fail in default configuration. > > But it's unreasonable to just wait for, say, Fedora 37 branch-off > > and break it in Rawhide for Fedora 38. > > The fallout will just be too big. > > > > Maintainers need time to get bugs, look into them, think, > > analyze, react and test --- and that's just if it fails correctly! > > Unfortunately, it's not just that the error paths are as dusty as they get > > because the program counter has never set foot on them before. > > Some maintainers might even find that > > picking a different hash function renders their code non-interoperable, > > or even that protocols they implement have SHA-1 hardcoded in the spec. > > Or that everything is ready, but real world deployments need another decade. > > Or that on-disk formats are just hard to change and migrate. > > Took git years to migrate from SHA-1, and some others haven't even started. > > There are gonna be investigations, planning, exceptions, upstream changes, > > opt-out mechanisms, arguing, compromises, waiting out, all kinds of things. > > It's gonna be big. Too big for a single release cycle. > > > > --- > > > > But how does one land something and give the distribution > > the extra cycles needed to react? That's not really clear to me. > > > > An obvious thing is to announce it in one cycle and land in another one. > > The downsides are well-documented > > in "The Hitchhiker's Guide to the Galaxy": > > announcements are one weak measure, and then it's too late. > > > > A second scheme I can come up with is a "jump scare". > > Break the functionality in Fedora 37 Rawhide, > > make most of the affected people realize the depth of the problem, > > then unbreak it. Break again for Fedora 38 and never fix. > > > > This could also be extended into "let one stable release slide'. > > Break in 37 Rawhide, unbreak on branched off 37, > > but never in Rawhide. > > > > But these are all rather... crude? > > Sure there should be better ways, > > preferably something explored before. > > I'm all for pulling this tooth out smoothly, > > but I need hints on how to do it. > > I hope that together we can devise a better plan than these. > > > &
Re: Can't fedpkg new-sources (403)
On Wed, Mar 16, 2022 at 3:47 PM Neal Becker wrote: > > Sorry if this is a duplicate message, previous one was held for moderation. > > $ fedpkg new-sources ~/Downloads/unuran-1.9.0.tar.gz > Could not execute new_sources: Fail to upload files. Server returns status 403 > > I haven't been active in packaging for some time, did I miss something? Just a guess, but given how new-sources also updates at least .gitignore, I think it expects maintainers to have the file in the checkout. Does it fail the same if you place it there and pass a relative filepath? fedpkg new-sources unuran-1.9.0.tar.gz ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On Wed, Mar 9, 2022 at 7:19 PM Daniel P. Berrangé wrote: > > On Wed, Mar 09, 2022 at 01:05:38PM -0500, Matthew Miller wrote: > > On Wed, Mar 09, 2022 at 05:40:50PM +, Daniel P. Berrangé wrote: > > > > But: maybe if we logged it _and_ had a tool people could run to > > > > look specifically for those log entries, we could do something like a > > > > Test > > > > Day where people could send in reports? > > > > > > Or just have it logging in rawhide, not in the final release. > > > > Yes, but we still need someone to look at those logs. > > Don't hate me for suggesting this, but the warning message on stderr > could suggest/request reporting the problem to bugzilla to bring it > to maintainer's attention. > >*** NOTICE: pid 1234 (firefox) used cryptographic signature >*** NOTICE: with deprecated SHA-1 algorithm. This usage >*** NOTICE: will be prevented by future policy. Please report >*** NOTICE: this problem to https://bugzilla.redhat.com > > Make it a one time message per process to avoid producing > pages of repeated text, and allow 'touch /etc/crypto-policies/dont-warn-me' > to hide it system wide. > > It would be irritating enough I've just checked and it's not just that my firefox already prints ~20 variations on "FAIL" on startup but I'm also pretty sure I see these for the first time, meaning I've never cared to check before. > to make at least some subset of rawhide > users followup with reporting bugs, and thus let maintainers understand > how badly they are impacted. > > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On Wed, Mar 9, 2022 at 7:05 PM Daniel P. Berrangé wrote: > > On Wed, Mar 09, 2022 at 06:45:49PM +0100, Alexander Sosedkin wrote: > > On Wed, Mar 9, 2022 at 6:22 PM Matthew Miller > > wrote: > > > > > > On Wed, Mar 09, 2022 at 12:14:28PM +0100, Alexander Sosedkin wrote: > > > > I left my crystal ball at home today, > > > > but I don't need it to say it'd be ~0 bugs filed if we log to syslog > > > > and ~3 if we log to stderr/stdout, all named > > > > "$CRYPTOLIB has no business messing up my stderr/stdout", > > > > which we'll promptly close by reverting the changes. > > > > > > Yeah, that's a little more cynically-phrased than I'd put it, but I had > > > similar thoughts. > > > > > > But: maybe if we logged it _and_ had a tool people could run to > > > look specifically for those log entries, we could do something like a Test > > > Day where people could send in reports? > > > > On one hand, this still is a risky territory > > of libraries leaning heavily into things that libraries shouldn't do > > because they can never guess the weird ways they're being used > > when they have existing interfaces to deny operations with some algorithms. > > > > On the other hand, this makes much more sense to me > > than the stdout/stderr proposal. > > The reason I suggested stderr was because it is about the only channel > you can have a reasonable guarantee of being able to use from a library > that has no knowledge about its execution environment. I don't think there is a reasonable guarantee you can use it. It's normal for a daemon to close inherited file descriptors and open something radically different as FD 3, right? And then we're writing our scary messages who knows where. > Security policies applied to procesess (SELinux, seccomp, namespaces or > containerization in general) can easily prevent ability to use journald, > syslog, or opening of log files, leading to messages not being visible. If the goal is some visibility, then it might... > At worst, with seccomp an attempt to use the blocked feature may lead > to an abort of the application. sigh. > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On Wed, Mar 9, 2022 at 6:22 PM Matthew Miller wrote: > > On Wed, Mar 09, 2022 at 12:14:28PM +0100, Alexander Sosedkin wrote: > > I left my crystal ball at home today, > > but I don't need it to say it'd be ~0 bugs filed if we log to syslog > > and ~3 if we log to stderr/stdout, all named > > "$CRYPTOLIB has no business messing up my stderr/stdout", > > which we'll promptly close by reverting the changes. > > Yeah, that's a little more cynically-phrased than I'd put it, but I had > similar thoughts. > > But: maybe if we logged it _and_ had a tool people could run to > look specifically for those log entries, we could do something like a Test > Day where people could send in reports? On one hand, this still is a risky territory of libraries leaning heavily into things that libraries shouldn't do because they can never guess the weird ways they're being used when they have existing interfaces to deny operations with some algorithms. On the other hand, this makes much more sense to me than the stdout/stderr proposal. Especially if it accompanies a drawn-out multicycle change, it could be a noticeable impact dampener. > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On Wed, Mar 9, 2022 at 4:40 PM Robbie Harwood wrote: > > Alexander Sosedkin writes: > > > Daniel P. Berrangé wrote: > > > >> Perhaps a useful first step is to just modify the three main > >> crypto libs (gnutls, openssl, and nss) to send a scary warnihg > >> message to stderr/syslog any time they get use of SHA1 in a > >> signature. Leave that active for a release cycle and see how > >> many bug reports we get. > > > > I left my crystal ball at home today, > > but I don't need it to say it'd be ~0 bugs filed if we log to syslog > > and ~3 if we log to stderr/stdout, all named > > "$CRYPTOLIB has no business messing up my stderr/stdout", > > It's clear you want SHA-1 gone, but the way you've written this maybe > isn't conveying what you wan, as it sounds like you're also unwilling to > process the bugs that result requesting its removal. (If you, who want > it gone, aren't willing to participate in that, why should maintainers > care?) Oh, nobody wants to go to the dentist, myself included. But it's as inevitable as it's not delegatable. Deprecating SHA-1 is no small thing, and one me could realistically do that for just a single small random thing. I can't realistically fix something big like git. I can't make DNSSEC deployments worldwide to move away from SHA-1. Besides small consultations, what I'm sure I can do is: keep postponing, raise discussions that don't convey the impact accurately, and then disable and collect my negative karma. I want to know, ultimately, how can I break it for devs but not the users so that 1. the need for it is communicated early, 2. all the relevant places are timely identified, 3. maintainers have a plenty of time to resolve it for good or opt out, 4. and the users are affected as late and as smoothly as possible. Hope these are all reasonable things to wish for. --- > As I understood the proposal, it would be for the crypto lib to log a > message like: > >[timestamp] /usr/bin/firefox used DEPRECATED SHA-1 invocation > > This is similar to what happened for /var/run: sure, it was annoying to > basically everyone involved, but the bugs also went to the relevant > packages. > > > which we'll promptly close by reverting the changes. > > I don't see why you'd do that instead of reassigning to the appropriate > packages or (better) helping them migrate. Because a cryptographic library polluting stdout/stderr is a bug! It's a bad idea on so many fronts: * for logging to be seen, it should go where the app logging goes * stderr/stdout is not always wired up to something at all * and when it is, *we break the output of the application* I think I've seen a bug when a library just opening a descriptor for its own private usage made it all go sideways, and you suggest actively interfering. --- Just for example, imagine we get a bug report: "none of my git scripts work anymore", telling us that users can no longer reliably script git because there's `/usr/libexec/git-core/git-clone used DEPRECATED SHA-1 invocation` all over the output they parse. We reassign it to git, git maintainers take their time and then decide: "we're gonna default to SHA-256 next month and disallow SHA-1 by default in 3 years because $VALID_REASONS, and for now we want $THIS_BEHAVIOUR instead". Or some other intricate, complicated and unique answer. Then what? Output of dozens of tools is still broken, users are rightfully upset, and, to add insult to injury, SHA-1 signatures still work. So, I guess, we're supposed to add an API to suppress the warning? Could be OK to use'em because it's gated behind an app opt-in or something. And then next release we disable it and then a different hundred of tools, those whose output nobody monitors or parses or even plumbs anywhere, break and we've effectively given them no forewarning. The <1% of those launching libreoffice from the terminal will have to intersect with those importing some specific format of documents to even get a slim chance of knowing why they should beware of the leopard. And it'll also break git again, giving a second round of headache to git maintainers, forcing them to roll-back interim solutions and deploy long-term ones. I think this approach manages to do it wrong twice, and that's not counting the very idea of libraries messing with stderr/stdout in the first place, which is, IMO, unthinkable. Breaking things and providing overrides to use them if really safe or necessary or opted into means interrupting maintainers just once to decide whether they override and keep using it or change to something else. Sounds much better to me. Less distractions, more consistency. Git breaks, git gets just a single prod to do the right long-term thing. Problem is, how does one stretch that in time and shield users from it. --- That being said, I'm
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On Wed, Mar 9, 2022 at 2:47 PM Richard W.M. Jones wrote: > > Previous tightening of crypto defaults caused problems with us > connecting to older ssh servers. > > I am particularly interested / worried about sshd from RHEL 5, 6 & 7 > for virt-p2v and virt-v2v conversions. This broke before, requiring > us to advise users to set the global policy for the machine to LEGACY > (thus ironically weakening crypto for everything). > > Also I have some ancient network equipment that cannot be upgraded but > needs older ssh protocols. I can't connect to it from Fedora unless I > set the crypto policy to LEGACY. > > Anyway I'm wondering if the SHA-1 change will impact ssh further? IIRC, the only SHA-1 thing that should be left in DEFAULT for SSH is SHA-1 as HMAC, which doesn't rely on collision resistance. So, not this round. > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On Wed, Mar 9, 2022 at 10:57 AM Daniel P. Berrangé wrote: > > On Wed, Mar 09, 2022 at 10:46:21AM +0100, Alexander Sosedkin wrote: > > On Wed, Mar 9, 2022 at 10:20 AM Daniel P. Berrangé > > wrote: > > > > > > On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote: > > > > We've been disabling it in TLS, but its usage is much wider than TLS. > > > > The next agonizing step is to restrict its usage for signatures > > > > on the cryptographic libraries level, with openssl being the scariest > > > > one. > > > > > > > > Good news is, RHEL-9 is gonna lead the way > > > > and thus will take a lot of the hits first. > > > > Fedora doesn't have to pioneer it. > > > > Bad news is, Fedora has to follow suit someday anyway, > > > > and this brings me to how does one land such a change. > > > > > > > > --- > > > > > > > > Fedora is a large distribution with short release cycles, and > > > > the only realistic way to weed out its reliance on SHA-1 signatures > > > > from all of its numerous dark corners is to break them. > > > > Make creation and verification fail in default configuration. > > > > But it's unreasonable to just wait for, say, Fedora 37 branch-off > > > > and break it in Rawhide for Fedora 38. > > > > The fallout will just be too big. > > > > > > If RHEL-9 has lead the way, what are the stats for real world > > > RHEL impact ? > > > > We'll know when the real world starts using RHEL-9 en masse? > > > > > What is/was the absolute number of packages and % number of > > > packages from the RHEL distro that saw breakage ? > > > > Does preventing the distro from installing altogether count as 100%? > > If yes, 100%. =) > > Jokes aside, I can't give you an accurate estimate yet. > > Perhaps a useful first step is to just modify the three main > crypto libs (gnutls, openssl, and nss) to send a scary warnihg > message to stderr/syslog any time they get use of SHA1 in a > signature. Leave that active for a release cycle and see how > many bug reports we get. I left my crystal ball at home today, but I don't need it to say it'd be ~0 bugs filed if we log to syslog and ~3 if we log to stderr/stdout, all named "$CRYPTOLIB has no business messing up my stderr/stdout", which we'll promptly close by reverting the changes. > > > Such figures can give us a better idea of impact on Fedora > > > beyond "too big". > > > > > > Assuming RHEL-9 has dealt with the problems, Fedora should > > > inherit those fixes, which gives us a good base for the most > > > commonly used / important packages in Fedora. > > > > Yeah, that's what I meant by the good news. > > But that won't solve all Fedora problems. > > > > > If the breakage % from RHEL was single digits, and those > > > were the most important packages to fix from Fedora's POV > > > too, then maybe the fall is not in fact "too big". It might > > > be sufficient to identify a few important remaining packages > > > to validate, and just accept the fallout for the remaining > > > less important packages in Fedora can be fixed after the > > > fact ? > > > > At a quick glance, > > I eyeball RHEL at ~2k packages and Fedora at ~22k packages. > > I think that limited analysis 's enough to safely claim > > that leaving the 90% of the packages you've labelled "less important" > > to be "fixed after the fact" is gonna be a disaster. > > One cycle doesn't sound enough. > > That 90% of packages are not all going to be using cryptographic > signatures though. Only a relatively small subset will do anything > crypto related, and most of that just be HTTPS and completely > outsourced to a crypto library. > > IOW of that 90% of packages not in RHEL, it could conceivably be > single digits that will be using cryptographic signatures with > SHA-1. An even smaller percentage of those will be considered > important enough to be blockers for this change. > > > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On Wed, Mar 9, 2022 at 10:20 AM Daniel P. Berrangé wrote: > > On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote: > > We've been disabling it in TLS, but its usage is much wider than TLS. > > The next agonizing step is to restrict its usage for signatures > > on the cryptographic libraries level, with openssl being the scariest one. > > > > Good news is, RHEL-9 is gonna lead the way > > and thus will take a lot of the hits first. > > Fedora doesn't have to pioneer it. > > Bad news is, Fedora has to follow suit someday anyway, > > and this brings me to how does one land such a change. > > > > --- > > > > Fedora is a large distribution with short release cycles, and > > the only realistic way to weed out its reliance on SHA-1 signatures > > from all of its numerous dark corners is to break them. > > Make creation and verification fail in default configuration. > > But it's unreasonable to just wait for, say, Fedora 37 branch-off > > and break it in Rawhide for Fedora 38. > > The fallout will just be too big. > > If RHEL-9 has lead the way, what are the stats for real world > RHEL impact ? We'll know when the real world starts using RHEL-9 en masse? > What is/was the absolute number of packages and % number of > packages from the RHEL distro that saw breakage ? Does preventing the distro from installing altogether count as 100%? If yes, 100%. =) Jokes aside, I can't give you an accurate estimate yet. > Such figures can give us a better idea of impact on Fedora > beyond "too big". > > Assuming RHEL-9 has dealt with the problems, Fedora should > inherit those fixes, which gives us a good base for the most > commonly used / important packages in Fedora. Yeah, that's what I meant by the good news. But that won't solve all Fedora problems. > If the breakage % from RHEL was single digits, and those > were the most important packages to fix from Fedora's POV > too, then maybe the fall is not in fact "too big". It might > be sufficient to identify a few important remaining packages > to validate, and just accept the fallout for the remaining > less important packages in Fedora can be fixed after the > fact ? At a quick glance, I eyeball RHEL at ~2k packages and Fedora at ~22k packages. I think that limited analysis 's enough to safely claim that leaving the 90% of the packages you've labelled "less important" to be "fixed after the fact" is gonna be a disaster. One cycle doesn't sound enough. > IIUC we have a simple workaround of letting someone set the > crypto policies on their machine back to LEGACY still Yes, I'll sure leave SHA-1 signatures allowed in LEGACY for some more years. Similarly, I could break it in FUTURE rather early, but nearly nobody would notice until it hits DEFAULT. > Regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Landing a larger-than-release change (distrusting SHA-1 signatures)
On Tue, Mar 8, 2022 at 8:52 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Mar 08, 2022 at 07:40:15PM +0100, Alexander Sosedkin wrote: > > the only realistic way to weed out its reliance on SHA-1 signatures > > from all of its numerous dark corners is to break them. > > Make creation and verification fail in default configuration. > > That sounds like a terrible plan. We should make newer hashes > the default, and we can make tools print a warning if sha1 is used > where it shouldn't, Yeah, that'd never gonna work. Cryptographic libraries aren't in position to do any meaningful logging, and even if they did, it'd be gleefully ignored until we break things. > but please don't break things on purpose. If you manage to come out with the way we can move forward to this century crypto that doesn't involve breaking things on purpose, definitely share one with us, you'd be our saviour. =( Yes, backwards compatibility is very important. Yes, you can still make a modern Fedora do RC4 or DES, with just a little bit of extra configuration. No, we must phase things out of defaults, there's no way around this. > For many many things sha1 is just fine. Just like md5 or even > crc32. Not everything is about cryptographic security. > Also, users will want to verify old signatures essentially forever. > This should be always possible. And finally, the world is huge, > and other users will provide sha1 signatures no matter what we do, > and it is better to check those than to completely ignore them. > > Zbyszek > > (This is a bit like browsers disliking self-signed certs and http:// > — it certainly is OK to make users aware of the issue, but actually > disallowing those is terribly annoying and will only result in users > jumping to different tools.) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Landing a larger-than-release change (distrusting SHA-1 signatures)
Hello, community, I need your wisdom for planning a disruptive change. Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 I believe we should start planning for the next cryptographic defaults tightening. And next time it's gonna be even more disruptive because of SHA-1 (again). SHA-1 is a hash function from 1995, which collision resistance is no longer to be relied upon for security [1]. At the same time, it's not like software has successfully migrated off it, not even close. It's not a question of "if" the world should migrate from it, sooner or later we must part ways with it. (Technically, some acute energy crisis or a collapse of civilization forever raising the costs of computations thousandfold would also do, but let's agree that migrating to a more modern hash is the way =) We've been disabling it in TLS, but its usage is much wider than TLS. The next agonizing step is to restrict its usage for signatures on the cryptographic libraries level, with openssl being the scariest one. Good news is, RHEL-9 is gonna lead the way and thus will take a lot of the hits first. Fedora doesn't have to pioneer it. Bad news is, Fedora has to follow suit someday anyway, and this brings me to how does one land such a change. --- Fedora is a large distribution with short release cycles, and the only realistic way to weed out its reliance on SHA-1 signatures from all of its numerous dark corners is to break them. Make creation and verification fail in default configuration. But it's unreasonable to just wait for, say, Fedora 37 branch-off and break it in Rawhide for Fedora 38. The fallout will just be too big. Maintainers need time to get bugs, look into them, think, analyze, react and test --- and that's just if it fails correctly! Unfortunately, it's not just that the error paths are as dusty as they get because the program counter has never set foot on them before. Some maintainers might even find that picking a different hash function renders their code non-interoperable, or even that protocols they implement have SHA-1 hardcoded in the spec. Or that everything is ready, but real world deployments need another decade. Or that on-disk formats are just hard to change and migrate. Took git years to migrate from SHA-1, and some others haven't even started. There are gonna be investigations, planning, exceptions, upstream changes, opt-out mechanisms, arguing, compromises, waiting out, all kinds of things. It's gonna be big. Too big for a single release cycle. --- But how does one land something and give the distribution the extra cycles needed to react? That's not really clear to me. An obvious thing is to announce it in one cycle and land in another one. The downsides are well-documented in "The Hitchhiker's Guide to the Galaxy": announcements are one weak measure, and then it's too late. A second scheme I can come up with is a "jump scare". Break the functionality in Fedora 37 Rawhide, make most of the affected people realize the depth of the problem, then unbreak it. Break again for Fedora 38 and never fix. This could also be extended into "let one stable release slide'. Break in 37 Rawhide, unbreak on branched off 37, but never in Rawhide. But these are all rather... crude? Sure there should be better ways, preferably something explored before. I'm all for pulling this tooth out smoothly, but I need hints on how to do it. I hope that together we can devise a better plan than these. So, how does one land a change that's bigger than a release cycle? [1] https://eprint.iacr.org/2020/014 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Packaging scrcpy with a precompiled APK dependency.
On Wed, Feb 16, 2022 at 10:00 PM Diego Herrera wrote: > > Hi. I was checking if the scrcpy software [1] could get packaged, but to > continue I need to know how to package an APK package file. For context, this > project consists on a Linux client and an Android server app that is uploaded > as an APK package by the client to an Android device using adb to share the > Android device screen. > > The project provides the sources to build that APK file, but it depends on > gradle and the Android SDK to build it. Even if we revive the gradle package, > I doubt that we can package the Android SDK since it requires it's own set of > licenses and I don't think that everything complies to the policies. I also > don't know if there is a way to compile the APK without those dependencies. > > On the other hand, the project also provides the precompiled APK that can get > directly added to the package (that's how other distros package this > software), but I doubt that adding a binary package complies with Fedora's > policies even if its not used on the same Fedora machine. > > Another idea that I thought of was to patch the program or add a script that > downloads the APK on the first run and save it on userspace. Technically you > are not packaging the binary, but in my opinion it's just a roundabout way to > get the same result. > > Is any of these approaches viable from a policy perspective? Is there a > better way to do this? Or should I desist on packaging this project on Fedora > for now? > > [1] https://github.com/Genymobile/scrcpy How's the version-to-version protocol compatibility doing? If it's stable, would it make sense to package the Android part in F-Droid and direct users to install it from there? > Best regards. > > -- > Diego Herrera C. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Bugzilla email confirmation notices from FAS
On Tue, Jan 11, 2022 at 6:04 PM Yaakov Selkowitz wrote: > > On Tue, 2022-01-11 at 11:58 -0500, Christopher wrote: > > Hi, > > > > Today, I received an email from f...@fedoraproject.org with the subject > > line "Fedora Account System: please verify your Bugzilla email > > address". This email has a unique link to accounts.fedoraproject.org. > > > > Based on the context, it seems legitimate. However, I noticed that > > clicking the link will take you to a sign-in page asking for > > credentials to your account. That seems strange to me, because it > > already has a unique link that's associated with the verification of a > > specific email in a specific FAS account, so asking for credentials > > should be completely unnecessary here. Asking for credentials makes > > this appear to be a phishing attempt, because that's how a phishing > > email would behave (appearance of legitimacy, requesting credentials > > when not needed). > > > > I think the FAS developers should remove the requirement to sign-in > > for these verification emails, to reduce the appearance/behavior of > > phishing. The email itself says these emails are "To improve > > security". If that is a goal, then Fedora systems should avoid > > training users to supply credentials when not needed. > > You want anyone who receives or intercepts those emails to be able to access > your account *without* logging in?!? An entity intercepting and reading your email should already be capable of anything besides installing your drivers (https://xkcd.com/1200). Is FAS somehow resistant to the "forgot password" button clicking "attack"? How? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Mon, Jan 10, 2022 at 5:20 PM David Cantrell wrote: > > On Wed, Dec 29, 2021 at 10:01:57AM -0500, Ben Cotton wrote: > >https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr > > > >== Summary == > >Currently, the RPM databases is located in `/var`. Let's move it to > >`/usr`. The move is already under way in rpm-ostree-based > >installations, and in (open)SUSE. > >[snip] > > Moving the RPM database to /usr feels incorrect to me, but we should move it > to gain the improvements as noted in the feature proposal. > > Numerous followups have noted the requirement that /usr contain read-only > content, that it be shareable across hosts, and similar concepts. While this > may or may not doable now like we could in the past, the bigger thing to me is > around the understanding of what /usr contains. It is generally understood > that /usr contains [most of] the installed system. What I think is a bigger > requirement or expection now is that one can tar up /usr and transport it to > another system or virtual machine or container and expect that it will > _probably_ work maybe with a bit of tinkering. This is a really valuable > thing to have for developers. Moving the RPM database to this tree adds a > component that is unnecessary and sort of out of place. > > "OK, but you can do tar -X" > > The tar example was simply that, an example. I feel the categorization of > system data is more important here. Panu brought this up on the referenced > RPM mailing list thread years ago. The original /var location for the RPM > database was fine, but we're at a point where we kind of have multiple > categories of things historically found in /var. > > Reading comments and talking to people, the long standing understanding of > /var is still "that's stuff you can rm -rf and the system will still work > fine". That's one interesting definition of "fine" if it's OK with wiping the system's (arguably) *only* non-disposable directory. > Technically you could remove the RPM database and the system still > function, but arguably would still be broken since you really want the RPM > database. This use case of removing the RPM database and still having a > functioning system is really only useful for data recovery scenarios. You're > ultimately going to reinstall. Probably. > > So maybe the question is more "what is the correct location for data like the > RPM database?" First, how is that data different from the rest of /var? It > is host-specific, it's updated by tools we run all the time, and it's > stateful. Losing it would render the system not really useful, though the > system would still function. Am I missing anything here? > > As Lennart noted, we have lots of examples in /usr of changing data. But I'd > say the difference between those examples (library symlinks, cache files, etc) > and the RPM database is that the loss of something like a library symlink or > cache file can be repaired easily but if you lose the RPM database, the system > is in an unrepairable state. > > As another example... If you use Bitlbee, this would be like losing your > account XML file in /var/lib/bitlbee. Sure, bitlbee still works, but that > file is important for Bitlbee to work for you. You have to remember to hang > on to that if you wipe /var or reinstall or whatever. I'd say the Bitlbee > files in /var/lib/bitlbee also fit this slightly different /var data > definition, just as an example. > > "But what about the FHS?" > > Ah, yes, the FHS. So, I am a fan of the FHS. I actually don't care that it > doesn't change every week and is relatively stable. Nothing in the FHS > prevents the addition of new top level directories. > > I would prefer we steer this conversation in the direction of determining a > new top level location to store data that fits this category of "stateful but > variable". > > /srv was introduced to provide a consistent location for data in this category > for server daemons (except mail). > > /media was introduced to provide a consistent location for removable media > mount points since distributions all did things slightly differently. > > /run was introduced for what was traditionally in /var/run. > > "So what are you suggesting?" > > I would like to see Fedora introduce a new top-level directory called: > > /state > > That holds the RPM database and other variable and stateful data. This keeps > it out of the /usr tree and can serve as a location for future data in this > category. If I ever see a system with /state I'll automatically assume this is the only location that's not wiped on a reboot, invented because the admin gave up on denylisting useless stuff in /var. The whole proposal is kinda sad to read. It's 2022 and we're catering to filesystem-level rollbacks. Filesystem rollbacks *are* a gigantic unsubtle hammer that should not be used in an automated manner, or better yet, not used at all. As much as you don't do filesystem rollbacks to undo paragraph deletions in
Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
On Wed, Dec 8, 2021 at 6:10 PM Björn Persson wrote: > > Chris Adams wrote: > > Once upon a time, Björn Persson said: > > > Chris Adams wrote: > > > > If the admin has done one thing to lock down the system, then they can > > > > do another (removing the sulogin --force addition). > > > > > > How do you propose to ensure that the admin is made aware of the need > > > to do that? > > > > The same way as any change - documentation. > > Introducing a new security hole is not just a change like any other > change. > > Sysadmins read documentation to find solutions when they know that they > have a problem to solve. They rarely read documentation to look for > problems they don't know about, and they don't regularly re-read every > document to look for potentially insecure changes. > > > > Experienced sysadmins won't just instinctively know that in this new > > > release of this particular distribution they need to run this special > > > command to prevent boot problems from granting root access to whoever > > > can type on the keyboard. > > > > It's not a "special command", it's just removing an RPM > > Po-tay-to, po-tah-to. > > > I don't install a brand new OS and give it to users without checking it > > out myself > > Does "checking it out" include breaking the system in every way you can > think of, to see whether one of them yields a root shell? > > > (and reading at least the release notes). > > Do you also read the release notes of all previous releases just in > case an obscure weakness was introduced in an old release that you > never used, and has been in place since then? > > > This is NOT some new "hole" - out of the box, Fedora already allows > > someone with console access to get root access (in less convenient, but > > more confusing, ways). > > What you're actually saying is: There is an old hole that we hope > sysadmins are aware of and know how to close if they need to, and > therefore it's fine to punch another hole in a hidden place where > sysadmins won't think to look. Sorry, but this one is a tiny brick at the entrance into a gigantic dark scary hole called 'physical access', which usually just trips someone up. Yes, I can imagine a convoluted specifically constructed scenario where it can play the pivotal role in the security of the overall system. Meaning, yes, if you manually build the entire missing wall around it, yanking it out would be bad for you, sure. That still doesn't deter me from arguing this is a bad default worth flipping with all the fanfare we can get about it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Schedule for Monday's FESCo Meeting (2021-08-23)
On Fri, Aug 27, 2021 at 6:28 PM przemek klosowski via devel wrote: > > > On 8/25/21 4:54 AM, Alexander Sosedkin wrote: > > It's not ideal if one obsolete website forces downgrading the security > potentially for all the connections. I hope 5) is addressing that. > > That's something apps and only apps can handle. > > Well, but if the system policy says that TLS1.0 is banned, the only way for > the app to downgrade would be if it had its own TLS stack, right? The right way is to make the library provide an API that overrides these defaults, and the application to call that API when it's confident it should deviate from the distribution defaults. The current way is that some libraries allow such overriding and some don't. > I do realize that the current policy mechanism is not designed for narrow > deviations, I am just pointing out that it's not ideal because in practice > people downgrade because they need narrow deviations for specific > connections, and as you well know, relaxing the rules for all connections > opens the door to downgrade attacks even on the connections that are capable > of TLS2.0. > > I am asking if there is another way, for instance by having a per-interface > policies, and setting up the relaxed rules for an interface that routes > traffic to this one deficient remote endpoint. It'd be very interesting, hard, and abstraction-permeating to make crypto library configuration depend on endpoints or interfaces, but this is definitely something that should start from within either apps or crypto libraries themselves. crypto-policies is the furthermost component away from things like interfaces and endpoints. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Schedule for Monday's FESCo Meeting (2021-08-23)
On Tue, Aug 24, 2021 at 8:57 PM przemek klosowski via devel wrote: > > > On 8/23/21 5:49 AM, Alexander Sosedkin wrote: > > Sure. Crypto-policies are there to give you control of what's enabled, > > ideally what's enabled by default. > > > > 1) There's a blanket `update-crypto-policies --set LEGACY` > > 2) There's a possibility to reenable disabled algorithms with custom > > policies, > > allowing to go even lower than LEGACY (which you > > shouldn't really do on public networks, but who's there to stop you) > > 3) (F35+) There's a possibility to reenable algorithms per backends, > > say, for NSS, Java or krb5 only > > 4) (In an ideal world) crypto-policies settings should act as defaults, > > meaning apps should be able to further modify them, > >offer weaker methods with a warning, etc > It's not ideal if one obsolete website forces downgrading the security > potentially for all the connections. I hope 5) is addressing that. That's something apps and only apps can handle. > > 5) There are total per-backend opt-out mechanisms / procedures > What is the 'backend' in this context? Since the protocol downgrades are > required by obsolete endpoints to which we're trying to connect, you're > suggesting 'per IP' or 'per-subnet' opt-out, right? Does it require > creating separate network interfaces and custom routes? Slow down. "Backend" = component crypto-policies generates configuration for: openssl, krb5, java to name a few. `ls /etc/crypto-policies/back-ends` If apps want to do something per IP, subnet, domain etc, they need to handle the required downgrades themselves. Crypto-policies are just for setting defaults system-wide in a uniform fashion by controlling configuration files. Thus narrow deviations from these defaults are way out of scope. > > 4 is what broke it here (gnutls currently uses hard-denylisting), > > but, in general, you still have all the other ways. > > They aren't something we can recommend to all openconnect users, > > but we've compromised on not-hard-disabling DTLS 0.9 specifically > > until we fix 4 more thoroughly. > > > > If an administrator of the specific host wants to modify or bypass > > crypto-policies, it's entirely within their power to do so > > and nobody intends (or is able to, for that matters) hinder that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Schedule for Monday's FESCo Meeting (2021-08-23)
On Tue, Aug 24, 2021 at 12:07 AM Chris Adams wrote: > > Once upon a time, Alexander Sosedkin said: > > Sure. Crypto-policies are there to give you control of what's enabled, > > ideally what's enabled by default. > > > > 1) There's a blanket `update-crypto-policies --set LEGACY` > > 2) There's a possibility to reenable disabled algorithms with custom > > policies, > >allowing to go even lower than LEGACY (which you > >shouldn't really do on public networks, but who's there to stop you) > > 3) (F35+) There's a possibility to reenable algorithms per backends, > >say, for NSS, Java or krb5 only > > 4) (In an ideal world) crypto-policies settings should act as defaults, > >meaning apps should be able to further modify them, > > offer weaker methods with a warning, etc > > 5) There are total per-backend opt-out mechanisms / procedures > > Missing #4 is what makes a lot of this not as useful. Yes, and consider myself to be the person who needs the least amount of convincing on that subject [1]. Work is underway to shift away from it in gnutls case. > I understand the effort that has gone into this > and appreciate stepping up security, > but... what matters as a user is "can I get to this site in Firefox", > "does this VPN work", etc. Browsers are probably the highest-impact > user of this, and it is all-or-nothing there AFAIK. Having to lower the > level across the board so that I can download router firmware images or > connect to my work VPN kind of scraps all the effort. [1] https://gitlab.com/gnutls/gnutls/-/issues/1172 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Schedule for Monday's FESCo Meeting (2021-08-23)
On Sun, Aug 22, 2021 at 11:00 PM Chris Adams wrote: > > Once upon a time, Dan Čermák said: > > #2659 Arbitration request: Crypto policy prevents VPN connections > > https://pagure.io/fesco/issue/2659 > > VPN requirements are a problem for increasing the encryption strength. > I have to connect to Cisco Meraki VPNs for work, and Libreswan has > disabled the necessary level of encryption. strongSwan still supports > them, so I use that instead (which, the NetworkManager plugins appear to > default to libreswan if it is installed, so I have to make sure it is > not). > > Even websites have problems; I went back and forth with another major > network equipment vendor because their support site HTTPS was only > supporting weaker methods. In the end, the only solution with Fedora > was to just use Google Chrome (which doesn't follow the system-wide > policy). I have to access that site for my job. > > It's unfortunate, but I must use VPNs and some websites. Fedora needs > to continue to support the older/weaker encryption methods in some form, > ideally via an opt-out mechanism for the system-wide crypto policies, or > allowing browsers to offer weaker methods with a warning or something. Sure. Crypto-policies are there to give you control of what's enabled, ideally what's enabled by default. 1) There's a blanket `update-crypto-policies --set LEGACY` 2) There's a possibility to reenable disabled algorithms with custom policies, allowing to go even lower than LEGACY (which you shouldn't really do on public networks, but who's there to stop you) 3) (F35+) There's a possibility to reenable algorithms per backends, say, for NSS, Java or krb5 only 4) (In an ideal world) crypto-policies settings should act as defaults, meaning apps should be able to further modify them, offer weaker methods with a warning, etc 5) There are total per-backend opt-out mechanisms / procedures 4 is what broke it here (gnutls currently uses hard-denylisting), but, in general, you still have all the other ways. They aren't something we can recommend to all openconnect users, but we've compromised on not-hard-disabling DTLS 0.9 specifically until we fix 4 more thoroughly. If an administrator of the specific host wants to modify or bypass crypto-policies, it's entirely within their power to do so and nobody intends (or is able to, for that matters) hinder that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Source-git SIG report #1 (June 2021)
On Tue, Jun 29, 2021 at 3:38 PM Tomas Tomecek wrote: > * Can you imagine maintaining Fedora's 30k+ packages in a single repo? > Without some git-fetch magic it would be unbearable to perform a > git-pull. I cannot imagine *not* doing this, maintaining a distro and preserving any sanity in the process. I cannot imagine having all your updates based on a moving target. I cannot imagine why have side-tags, why decouple building from committing, why make mass-rebuilds a big thing instead of a topical branch they are and why make composes a big thing and not just a commit in a repo of 'the state of Fedora'. Composing this email takes about the same time (3m) as cloning [1], the second largest package collection on repology, at full depth. The tip of it, which the users actually need to download when they update, weights <25M. --depth=1 clone takes 10 seconds. [1] time git clone g...@github.com:NixOS/nixpkgs ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
