F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
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.
== Owner ==
* Name: [[User:Asosedkin| Alexander Sosedkin]] * Email: asosedki@redhat.com
== Detailed Description ==
Secure defaults are an evermoving target. Fedora 28 had [[Changes/StrongCryptoSettings|StrongCryptoSettings]]. Fedora 33 had [[Changes/StrongCryptoSettings2|StrongCryptoSettings2]]. Fedora 39 should have [[Changes/StrongCryptoSettings3|StrongCryptoSettings3]].
By Fedora 39, the policies will be, in TLS perspective: LEGACY MACs: All HMAC with SHA1 or better + all modern MACs (Poly1305 etc.) Curves: all prime >= 255 bits (including Bernstein curves) Signature algorithms: SHA-1 hash or better (no DSA) Ciphers: all available > 112-bit key, >= 128-bit block (no RC4 or 3DES) Key exchange: ECDHE, RSA, DHE (no DHE-DSS) DH params size: >=2048 RSA params size: >=2048 TLS protocols: TLS >= 1.2
DEFAULT MACs: All HMAC with SHA1 or better + all modern MACs (Poly1305 etc.) Curves: all prime >= 255 bits (including Bernstein curves) Signature algorithms: with SHA-224 hash or better (no DSA) Ciphers: >= 128-bit key, >= 128-bit block (AES, ChaCha20, including AES-CBC) Key exchange: ECDHE, RSA, DHE (no DHE-DSS) DH params size: >= 2048 RSA params size: >= 2048 TLS protocols: TLS >= 1.2
FUTURE MACs: All HMAC with SHA256 or better + all modern MACs (Poly1305 etc.) Curves: all prime >= 255 bits (including Bernstein curves) Signature algorithms: SHA-256 hash or better (no DSA) Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated Encryption (AE) ciphers Key exchange: ECDHE, DHE DH params size: >= 3072 RSA params size: >= 3072 TLS protocols: TLS >= 1.2
The flagship change this time will be distrusting SHA-1 signatures on the cryptographic library level, affecting more than just TLS.
OpenSSL will start blocking signature creation and verification by default, with the fallout anticipated to be wide enough for us to roll out the change across multiple cycles with multiple forewarnings to give developers and maintainers ample time to react:
Fedora 36: * SHA-1 signatures are distrusted in FUTURE policy (opt-in) * TEST-FEDORA39 policy is provided * creating and verifying SHA-1 signatures is logged to ease reporting bugs
Fedora 37 [[Changes/StrongCryptoSettings3Forewarning3|StrongCryptoSettings3Forewarning1]]: * (was initially reserved to implement logging of SHA-1 signature operations)
'''Fedora 38 [[Changes/StrongCryptoSettings3Forewarning3|StrongCryptoSettings3Forewarning2]]''': * policies are updated, most notably * SHA-1 signatures are distrusted in DEFAULT policy * changes are reverted in branched f38 in time for Beta and do not reach users
Fedora 39 [[Changes/StrongCryptoSettings3|StrongCryptoSettings3]]: * changes reach users
The plan is subject to change if it goes sideways somewhere along the way.
So, in Fedora 36, 37 and ''38 released'' distrusting SHA-1 signatures will be opt-in. In ''Fedora 38 rawhide'' and Fedora 39 distrusting SHA-1 signatures will happen by default.
== Feedback ==
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... A discussion] has been raised on fedora-devel, [https://lwn.net/Articles/887832 a summary] is available on LWN.
A change has the potential to prove disruptive and controversial, with much effort being focused on stretching it out in time.
There seems to be a consensus that the change has to be done eventually, but the ideal means of implementing it are in no way clear. The decision to discover code reliant on SHA-1 signatures by blocking creation/verification has not gathered many fans, but not many alternative proposals have been raised in return. A notable one, making the library somehow log the offending operations, has been incorporated in the proposal, though the effectiveness of it is yet to be seen in practice. Another notable takeaway point is the need to call for testing, which would be done in form of writing four Fedora Changes and testing SHA-1 signature distrusting during Fedora 37 & ''38'' Test Days. The change owner doesn't see the plan as an ideal one and continues to be open for feedback.
== Benefit to Fedora ==
Fedora 39 will ship with more secure defaults to better match the everchanging landscape of cryptographic practices. TLS 1.0 / 1.1 protocol version will be disabled as they're [https://datatracker.ietf.org/doc/rfc8996 deprecated], minimum key sizes will be raised to keep up with the computational advances etc.
Distrusting SHA-1 signatures specifically is expected to trigger a topical distribution-wide crackdown on [https://eprint.iacr.org/2020/014 weak] cryptography, raising the security of the distribution moving forward.
== Scope ==
* Proposal owners: implement changes described in Summary and Dependencies sections
* Other developers: Test your applications with TEST-FEDORA39 policy. Move away from trusting SHA-1 signatures; ideally in time for F38 branch-off, for F39 release at the latest.
Follow [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]]: 1. move away from trusting SHA-1 signatures entirely, or 2. distrust them by default and require explicit user opt-in to use a workaround
* Release engineering: Not sure if mass-rebuild is required if we land the change right after f38 branch-off. Maybe a "preview" mass-rebuild can be done with a special build in the F37 timeframe to cut down on F38 FTBFS.
* Policies and guidelines: update needed
CryptoPolicies section of the packaging guidelines will have to be updated to reflect that SHA-1 signatures must not be trusted by default and provide guidance for openssl and gnutls. Components using workaround APIs must not use them without explicit user opt-in and must be added to a list of applications using a workaround API.
* Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: not with Fedora 37-era ones
== Upgrade/compatibility impact ==
See "User experience".
Upgrade-time issues aren't specifically anticipated; if any were to arise, testing should find them in ''Fedora 38''-times, to be fixed by Fedora 39 release at the latest.
Administrators willing to sacrifice security can apply LEGACY or FEDORA38 policies.
== How To Test ==
=== Testing actively ===
On a ''Fedora 38 rawhide'' system, install crypto-policies-scripts package and switch to a more restrictive policy with `update-crypto-policies --set TEST-FEDORA39`.
Proceed to use the system as usual, identify the workflows which are broken by this change.
Verify that the broken functionality works again if you the policy is relaxed back with, e.g., `update-crypto-policies --set TEST-FEDORA39:SHA1`, file bug reports against the affected components if not filed already. Please start your ticket title with `StrongCryptoSettings3: `, mention this change page, the version of crypto-policies package and the policies under which your workflow does and does not work.
Especially brave souls can dare to try `update-crypto-policies --set FUTURE` instead, though this policy is more aggressive than the upcoming defaults.
=== Testing passively ===
On a ''Fedora 38 released'' system, install a special logging tool from https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer Run it and proceed to use your system. Once the tool notifies you about about soon-to-be-blocked SHA-1 signature operations, identify the component and actions leading to these operations, verify that repeating them leads to logging more entries. Ideally also verify that switching to a stricter policy breaks the workflow. File bug reports against the affected components if not filed already. Please start your ticket title with `StrongCryptoSettings3: ` and link to this change page.
== User Experience ==
Things will break. All kinds of things depending on SHA-1 signatures, openly and secretly. * On Fedora 36-37 they'll break opt-in. * '''On Fedora 38 rawhide they'll break by default.''' * '''On Fedora 38 released they'll behave like in Fedora 37.''' * On Fedora 39 they'll break by default again, including the released version.
== Dependencies ==
A small coordinated change with openssl is required. In Fedora 38, openssl should start distrusting SHA-1 signatures when used with no configuration file. This does not affect the majority of scenarios, only applications that do not follow system-wide cryptographic policies.
All reverse dependencies of core cryptographic libraries are affected, especially openssl ones relying on SHA-1 signatures.
== Contingency Plan ==
* Contingency mechanism: not needed for F38, change will be reverted before Beta anyway * Contingency deadline: not needed for F38, change will be reverted before Beta anyway * Blocks release? No
== Documentation == Workaround API should be added to [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]]. Packaging guidelines should be modified accordingly.
== Release Notes ==
To be done, similarly to https://pagure.io/fedora-docs/release-notes/issue/829
On Mon, Aug 29, 2022 at 2:30 PM Ben Cotton bcotton@redhat.com wrote:
- Release engineering: Not sure if mass-rebuild is required if we
land the change right after f38 branch-off. Maybe a "preview" mass-rebuild can be done with a special build in the F37 timeframe to cut down on F38 FTBFS.
Please file an issue with releng: https://pagure.io/releng/new_issue
This is required by FESCo for all System-Wide Change proposals anyway.
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? - changing the default in ELN only first?
On Mon, Aug 29, 2022 at 10:48 PM Miro Hrončok mhroncok@redhat.com 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.
How about this:
Drop the term 'jump scare' entirely. IMHO it just sounds bad.
Rework the change so it's basically planning on making this change in f38.
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.
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?
* 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.
* setup a tracking bug to track the issues, so we can make a more informed decision before f38 beta.
Thoughts?
kevin
On Tue, Sep 13, 2022 at 1:35 PM Kevin Fenzi kevin@scrye.com wrote:
- setup a tracking bug to track the issues, so we can make a more
informed decision before f38 beta.
This should be the tracker in the Changes Tracking component. Normally those are created after a proposal is approved by FESCo, but I can pre-create it if necessary. I've done that for some Python changes, e.g.
On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi kevin@scrye.com 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.
On Wed, Sep 14, 2022 at 11:45:16AM +0200, Alexander Sosedkin wrote:
On Tue, Sep 13, 2022 at 7:35 PM Kevin Fenzi kevin@scrye.com 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".
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.
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.
kevin
On Wed, Sep 14, 2022 at 6:40 PM Kevin Fenzi kevin@scrye.com 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 kevin@scrye.com 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/...
Alexander Sosedkin wrote:
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.
IMHO, a change that breaks so many things that you expect it to take more than 6 months to fix the breakage across the entire distribution is just unacceptable to begin with and should just not be done altogether, ever. At least not as long as it is expected to break so many things. Maybe in 10 or 20 years, you can even consider dropping SHA-1. The real world does not move as fast as the progress in cryptanalysis, you just have to accept that.
Maybe it can work to distrust SHA-1 in some particularly security-critical contexts, e.g., make RPM distrust SHA-1 signatures for packages installed on the system (but not, e.g., in a mock chroot targeting some older RHEL!) by default, with an easy way to change that default (I am thinking of something like "echo 'trust_sha1_sigs 1' >/etc/rpm/macros.trustsha1"). But disallowing SHA-1 systemwide, with no regards to what the actual application is and what level of security it provides, is just insane, and will just lead to applications bundling their own SHA-1 implementation and possibly even their own PGP signature implementation to work around your deliberate breakage.
Kevin Kofler
On 9/15/22 00:59, Kevin Kofler via devel wrote:
Alexander Sosedkin wrote:
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.
IMHO, a change that breaks so many things that you expect it to take more than 6 months to fix the breakage across the entire distribution is just unacceptable to begin with and should just not be done altogether, ever. At least not as long as it is expected to break so many things. Maybe in 10 or 20 years, you can even consider dropping SHA-1. The real world does not move as fast as the progress in cryptanalysis, you just have to accept that.
Maybe it can work to distrust SHA-1 in some particularly security-critical contexts, e.g., make RPM distrust SHA-1 signatures for packages installed on the system (but not, e.g., in a mock chroot targeting some older RHEL!) by default, with an easy way to change that default (I am thinking of something like "echo 'trust_sha1_sigs 1' >/etc/rpm/macros.trustsha1"). But disallowing SHA-1 systemwide, with no regards to what the actual application is and what level of security it provides, is just insane, and will just lead to applications bundling their own SHA-1 implementation and possibly even their own PGP signature implementation to work around your deliberate breakage.
Please read the actual proposal: this is about SHA-1 *signatures*. Not the hash itself.
- Panu -
On Mon, Aug 29, 2022 at 02:30:44PM -0400, 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.
This breaks a bunch of V2V use cases where we want to examine old guests which have RPM databases using SHA1. Also we want to ssh to remote machines running RHEL 5-era sshd.
The flagship change this time will be distrusting SHA-1 signatures on the cryptographic library level, affecting more than just TLS.
OpenSSL will start blocking signature creation and verification by default, with the fallout anticipated to be wide enough for us to roll out the change across multiple cycles with multiple forewarnings to give developers and maintainers ample time to react:
The openssl change was a bad idea in RHEL 9, and it's going to be a bad idea in Fedora too.
Rich.
Aug 29, 2022 1:32:21 PM Ben Cotton bcotton@redhat.com:
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.
I think this is a bad idea. It's quite hostile to packagers. It will break rawhide for months and make it very difficult to stabilize the distro before the beta freeze or do any type of rebuild. It very well may affect other Changes. It will still cause untold problems even if you revert it before the beta freeze. Please test this in COPR (as Miro already said) or somewhere else instead of destabilizing the distro. You can analyze the COPR failures and report bugs just like the Python SIG does for new Python major versions. -- Best,
Maxwell G (@gotmax23) Pronouns: He/Him/His
On Wed, 2022-09-07 at 17:47 +0000, Maxwell G via devel wrote:
I think this is a bad idea. It's quite hostile to packagers. It will break rawhide for months and make it very difficult to stabilize the distro before the beta freeze or do any type of rebuild. It very well may affect other Changes. It will still cause untold problems even if you revert it before the beta freeze. Please test this in COPR (as Miro already said) or somewhere else instead of destabilizing the distro. You can analyze the COPR failures and report bugs just like the Python SIG does for new Python major versions.
I have no stake in this but participated in the test day (I don't think anyone else did?) so I would like to give my 2 cents.
First for the results. I only noticed two issues: RPM Fusion signing keys and libimobiledevice no longer pairing with phones. Both are "trivial" issues. The former is a quick fix, the latter the maintainer has been notified and has expressed interest in modifying the codebase to switching from SHA1 to something like SHA256. COPR also had issues but again, that was a quick fix.
Secondly, I agree that it is hostile to packagers. I filed an issue and the packager was kind of blindsided by the proposal. I have no issue with the term jump scare because I think such a radical change does need to "scare" people otherwise complacency leads to people being slow to migrate (see Python 2 -> 3 and people forking 2, despite having over a decade to switch to 3 for example). So maybe such a big change should have more communication and emphasis.
Now while I only found a few issues doing testing, I have no doubt other people will have more exotic setups like specific hardware, VPNs, third party repos, etc. where things will break. Although I should say that I did testing across a wide variety of software including Tor, git, SSH and so on so assuming a relatively vanilla setup, most people should be fine.
Anyway I agree on paper about testing it on COPR to avoid affecting the main distro, but I think that something like this can only encourage people to fix (or drop) software if there is intentional breakage.
Ben Cotton kirjoitti 29.8.2022 klo 21.30:
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.
To test this, I did enable TEST-FEDORA39 on my system, first installed as Fedora 24, now running 36. For some rpm and dnf operations, I get the following kind of errors:
error: rpmdbNextIterator: skipping h# 740 Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD Header SHA256 digest: OK Header SHA1 digest: OK
I first noticed this with 'dnf upgrade', simplified to 'dnf reinstall glibc', perhaps the best reproduces is 'rpm -qa > /dev/null'.
Regardless of these errors, all the commands work as expected. Still I wonder, is it expected that old installations will see, and keep seeing, these errors after distrusting SHA-1?
On Thu, 2022-09-15 at 16:18 +0300, Otto Liljalaakso wrote:
To test this, I did enable TEST-FEDORA39 on my system, first installed as Fedora 24, now running 36. For some rpm and dnf operations, I get the following kind of errors:
error: rpmdbNextIterator: skipping h# 740 Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD Header SHA256 digest: OK Header SHA1 digest: OK
I first noticed this with 'dnf upgrade', simplified to 'dnf reinstall glibc', perhaps the best reproduces is 'rpm -qa > /dev/null'.
Regardless of these errors, all the commands work as expected. Still I wonder, is it expected that old installations will see, and keep seeing, these errors after distrusting SHA-1?
That is the RPM Fusion signing key.
Tommy Nguyen kirjoitti 15.9.2022 klo 16.28:
On Thu, 2022-09-15 at 16:18 +0300, Otto Liljalaakso wrote:
To test this, I did enable TEST-FEDORA39 on my system, first installed as Fedora 24, now running 36. For some rpm and dnf operations, I get the following kind of errors:
error: rpmdbNextIterator: skipping h# 740 Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD Header SHA256 digest: OK Header SHA1 digest: OK
I first noticed this with 'dnf upgrade', simplified to 'dnf reinstall glibc', perhaps the best reproduces is 'rpm -qa > /dev/null'.
Regardless of these errors, all the commands work as expected. Still I wonder, is it expected that old installations will see, and keep seeing, these errors after distrusting SHA-1?
That is the RPM Fusion signing key.
Yes, I have RPM Fusion enabled. I also see that there are more problems with RPM Fusion:
$ sudo dnf install vlc ... Problem opening package faad2-libs-2.10.0-3.fc36.x86_64.rpm Problem opening package libdca-0.0.7-5.fc36.x86_64.rpm Problem opening package live555-2022.02.07-1.fc36.x86_64.rpm The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: GPG check FAILED
If I install vlc when the DEFAULT policy is in force, then put TEST-FEDORA39 back, I cannot remove vlc any more:
$ sudo dnf remove vlc ... Remove 96 Packages Freed space: 377 M Is this ok [y/N]: y Running transaction check error: rpmdbNextIterator: skipping h# 526 Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD Header SHA256 digest: OK Header SHA1 digest: OK Error: An rpm exception occurred: package not installed
So maybe it is just that, for Fedora 36 at least, RPM Fusion it not compatible with the new crypto settings.
I also see the following key ids in the errors I reported in the original message. How can I check what those are, more RPM Fusion keys?
6dc1be18 d651ff2e 94843c65
On Sep 15, 2022, at 10:26 AM, Otto Liljalaakso otto.liljalaakso@iki.fi wrote:
Tommy Nguyen kirjoitti 15.9.2022 klo 16.28:
On Thu, 2022-09-15 at 16:18 +0300, Otto Liljalaakso wrote: To test this, I did enable TEST-FEDORA39 on my system, first installed as Fedora 24, now running 36. For some rpm and dnf operations, I get the following kind of errors:
error: rpmdbNextIterator: skipping h# 740 Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD Header SHA256 digest: OK Header SHA1 digest: OK
I first noticed this with 'dnf upgrade', simplified to 'dnf reinstall glibc', perhaps the best reproduces is 'rpm -qa > /dev/null'.
Regardless of these errors, all the commands work as expected. Still I wonder, is it expected that old installations will see, and keep seeing, these errors after distrusting SHA-1?
That is the RPM Fusion signing key.
Yes, I have RPM Fusion enabled. I also see that there are more problems with RPM Fusion:
$ sudo dnf install vlc ... Problem opening package faad2-libs-2.10.0-3.fc36.x86_64.rpm Problem opening package libdca-0.0.7-5.fc36.x86_64.rpm Problem opening package live555-2022.02.07-1.fc36.x86_64.rpm The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: GPG check FAILED
If I install vlc when the DEFAULT policy is in force, then put TEST-FEDORA39 back, I cannot remove vlc any more:
$ sudo dnf remove vlc ... Remove 96 Packages Freed space: 377 M Is this ok [y/N]: y Running transaction check error: rpmdbNextIterator: skipping h# 526 Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD Header SHA256 digest: OK Header SHA1 digest: OK Error: An rpm exception occurred: package not installed
So maybe it is just that, for Fedora 36 at least, RPM Fusion it not compatible with the new crypto settings.
I also see the following key ids in the errors I reported in the original message. How can I check what those are, more RPM Fusion keys?
6dc1be18 d651ff2e 94843c65 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
A while back I reported the issue and someone said that it has to do with their sub key. Not much that can be done except report it to rpmfusion (unless it’s already been done).
In order to identify the rest of the keys, try:
rpm -qa gpg-pubkey* rpm -qi gpg-pubkey-keyid-goeshere
For now either disable rpmfusion or set the crypto policy back to default.
Tommy Nguyen kirjoitti 15.9.2022 klo 17.40:
On Sep 15, 2022, at 10:26 AM, Otto Liljalaakso otto.liljalaakso@iki.fi wrote:
So maybe it is just that, for Fedora 36 at least, RPM Fusion it not compatible with the new crypto settings.
I also see the following key ids in the errors I reported in the original message. How can I check what those are, more RPM Fusion keys?
6dc1be18 d651ff2e 94843c65
A while back I reported the issue and someone said that it has to do with their sub key. Not much that can be done except report it to rpmfusion (unless it’s already been done).
I tried searching bugzilla.rpmfusion.org, but could not find anything that looks relevant. I also wanted to search the mailing lists, but apparently, at the moment, RPM Fusion is not publicly archiving its mailing lists [1].
[1]: https://bugzilla.rpmfusion.org/show_bug.cgi?id=4759#c5
Anyhow, I did some more research. It looks like RPM Fusion has switched signing packages with SHA256, but in their repository for Fedora 36, there are older builds around that still use SHA1. At least the SHA1 ones that I found are older than the SHA256 ones.
RPM Fusion Fedora 37 repository seems to be all SHA256 already.
So, it looks like there is nothing to fix here, except maybe adding some note to testing instructions.
In order to identify the rest of the keys, try:
rpm -qa gpg-pubkey* rpm -qi gpg-pubkey-keyid-goeshere
Thanks, they are all from RPM Fusion.
Tommy Nguyen kirjoitti 16.9.2022 klo 6.51:
On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote:
RPM Fusion Fedora 37 repository seems to be all SHA256 already.
Thanks for doing the research. I plan on upgrading to the F37 beta soon. Have you done so already and what are your results?
I have the same plan, but currently I cannot fully upgrade my Fedora 36 [1], so Fedora 37 Beta has to wait until that is resolved.
However, this issue is easily reproducible in a Toolbox container. There, I see the reported problems for Fedora 36, but not for Rawhide. I have not tried Fedora 37, and do not plan to do so, because based on the information that has been gathered, I am convinced that the problem will be gone soon enough.
On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote:
Tommy Nguyen kirjoitti 15.9.2022 klo 17.40:
On Sep 15, 2022, at 10:26 AM, Otto Liljalaakso otto.liljalaakso@iki.fi wrote:
So maybe it is just that, for Fedora 36 at least, RPM Fusion it not compatible with the new crypto settings.
I also see the following key ids in the errors I reported in the original message. How can I check what those are, more RPM Fusion keys?
6dc1be18 d651ff2e 94843c65
A while back I reported the issue and someone said that it has to do with their sub key. Not much that can be done except report it to rpmfusion (unless it’s already been done).
I tried searching bugzilla.rpmfusion.org, but could not find anything that looks relevant. I also wanted to search the mailing lists, but apparently, at the moment, RPM Fusion is not publicly archiving its mailing lists [1].
Anyhow, I did some more research. It looks like RPM Fusion has switched signing packages with SHA256, but in their repository for Fedora 36, there are older builds around that still use SHA1. At least the SHA1 ones that I found are older than the SHA256 ones.
RPM Fusion Fedora 37 repository seems to be all SHA256 already.
So, it looks like there is nothing to fix here, except maybe adding some note to testing instructions.
In order to identify the rest of the keys, try:
rpm -qa gpg-pubkey* rpm -qi gpg-pubkey-keyid-goeshere
Thanks, they are all from RPM Fusion. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
I found this: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6410#c1
Again, not a very friendly response. The short is that they are currently in freeze so no action can be taken ATM.
On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote:
I found this: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6410#c1
Again, not a very friendly response. The short is that they are currently in freeze so no action can be taken ATM.
The rpmfusion f36 release repo isn't fixable as it is locked after f36 release.
Leigh Scott kirjoitti 17.9.2022 klo 10.27:
On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote:
I found this: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6410#c1
Again, not a very friendly response. The short is that they are currently in freeze so no action can be taken ATM.
I did not write that, Tommy did. Please be careful with attribution, especially with clips that can be interpreted as negative.
Other than that, great to see somebody from RPM Fusion involved in this thread!
On Sat, 2022-09-17 at 10:40 +0300, Otto Liljalaakso wrote:
Leigh Scott kirjoitti 17.9.2022 klo 10.27:
On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote:
I found this: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6410#c1
Again, not a very friendly response. The short is that they are currently in freeze so no action can be taken ATM.
I did not write that, Tommy did. Please be careful with attribution, especially with clips that can be interpreted as negative.
Other than that, great to see somebody from RPM Fusion involved in this
It was almost certainly a typo when editing the replies. I doubt they intended to misquote.
Anyway, I did successfully update to the F37 beta with the crypto policies at default. I have not tested re-enabling it because one package I depend on still has sha1 code.
Tommy Nguyen kirjoitti 17.9.2022 klo 10.44:
On Sat, 2022-09-17 at 10:40 +0300, Otto Liljalaakso wrote:
Leigh Scott kirjoitti 17.9.2022 klo 10.27:
On Thu, 2022-09-15 at 22:42 +0300, Otto Liljalaakso wrote:
I found this: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6410#c1
Again, not a very friendly response. The short is that they are currently in freeze so no action can be taken ATM.
I did not write that, Tommy did. Please be careful with attribution, especially with clips that can be interpreted as negative.
Other than that, great to see somebody from RPM Fusion involved in this
It was almost certainly a typo when editing the replies. I doubt they intended to misquote.
No malice assumed, and no harm done! I just wanted to point out the accident.
devel@lists.stg.fedoraproject.org
-
Alexander Sosedkin -
Ben Cotton -
Kevin Fenzi -
Kevin Kofler -
Leigh Scott -
Maxwell G -
Miro Hrončok -
Otto Liljalaakso -
Panu Matilainen -
Richard W.M. Jones -
Tommy Nguyen