#2865 Change: Strong crypto settings: phase 3, forewarning 2/2
Opened a month ago by bcotton. Modified 4 days ago

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.

Owners, do not implement this work until the FESCo vote has explicitly ended.
The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed.
See the FESCo ticket policy and the Changes policy for more information.


Breaking F38 intentionally and reverting the change after the branch point ("jump scare") is a no-go for me. -1

Metadata Update from @churchyard:
- Issue tagged with: meeting

a month ago

(would be very useful for me to collect terse preferred alternative proposals along with '-1's and thus discern, say, "do nothing in F38, flip the switch in F39 only" from, say, "I'm against the entire proposal, trust SHA-1 signatures forever")

I'm not against updating crypto policies when circumstances change ("SHA-1 no longer considered secure when used for X, so disallow SHA-1 for X by default" is probably a good idea) but I am against pushing this change to Fedora temporarily (months!), breaking things intentionally, just to find out what would be affected by the change. I think testing the new policy should be opt-in (or at least have more limited impact than "the entirety of Fedora Rawhide and all Fedora packagers"). For example, a COPR with updated crypto policies could be provided for testers. Or the policy update could be made in ELN only (similar to how other changes are tested there, like the s390x microarchitecture bump), and if things break there, things in Fedora Rawhide can be fixed without time pressure, and don't hold up the usual development process (i.e. no broken composes or blocked package rebuilds for soname bumps, etc.).

(ack, thanks. ELN has this change for months, opt-in is possible since Fedora 36 using TEST-FEDORA39 policy)

Honestly, I think the "jump scare" is a really good idea. It'll impact only those brave souls running Rawhide, which is a set of people both used to breakage and (generally) capable of understanding how to work around it.

In a practical sense, it's really the only option I can think of to avoid catastrophe at Fedora 39. There are probably dozens if not hundreds of places that are relying on SHA-1 signatures that we will never know about until this change is made. Far better for a bunch of us developers to stumble upon them than to wait until it hits end-users in Fedora 39 and results in huge amounts of bad press.

I'm +1 here. I'm also enabling TEST-FEDORA39 on my primary system right now.

I'm +1 on this because at some point, we need to disallow SHA-1. Some issues can be caught during package builds (if tests fail), but some of it only shows up when you use the application or use multiple applications together.

ACTION: nirik to bring proposal back to the devel list (sgallagh, 17:25:59)

Metadata Update from @sgallagh:
- Issue untagged with: meeting

18 days ago

Did the Action happen? I looked at fedora-devel, and there were messages after 13/09 (the date of the message above), but I don't think I saw anything that'd match "bring proposal back to the devel list".

Hmm, can we have a mode where using SHA-1 signatures results in a warning? (Either on the console or in the logs.) This would be much more palatable then getting strange refusals from various tools without a clear indication that the issue is about SHA-1.

Metadata Update from @zbyszek:
- Issue tagged with: meeting

5 days ago

Did the Action happen? I looked at fedora-devel, and there were messages after 13/09 (the date of the message above), but I don't think I saw anything that'd match "bring proposal back to the devel list".

Yes, I posted https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MUB52TTVKIWNRLRZDYOARO3COLV4FPNP/ with the proposal at least as I understood it. If that didn't match everyone's idea, sorry. The change owners didn't really like that plan, so they wanted to stick to the orig proposal.

Hmm, can we have a mode where using SHA-1 signatures results in a warning? (Either on the console or in the logs.) This would be much more palatable then getting strange refusals from various tools without a clear indication that the issue is about SHA-1.

There were such requests since day one, yes,
despite it's unlikely it'll be actually widely used.
I've written a tool for that, should be in the proposals as well, IIRC:

https://gitlab.com/redhat-crypto/fedora-sha1sig-tracer
https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer

fedora-sha1sig-tracer is an opt-in tool. Once you know you have the problem, it may be useful to diagnose how it occurs. But I'm talking about an approach from a different side: add the following code somewhere in openssl:

int check_sha1_signature() {
  static bool warned = false;
  if (!warned) {
     fprintf(stderr, "Program is using deprecated SHA1 signatures. See https://somewhere.org/explanation");
     warned = true;
  }
  ...
}

This has been discussed at lengths in the original announcement, and I'll keep insisting this is a bad idea even if something monitors whenever this stderr goes to.

This will be discussed during FESCo meeting today at 17:00 UTC. @asosedkin (and anyone else interested) are invited!

I re-read the discussions, and I don't understand why you're trying to make this so painful.

https://bugzilla.redhat.com/show_bug.cgi?id=2064740: people are asking for easy per-process mechanism. You even said that this should be simple, with an envvar. Can we please have this? (And no, the suid helper that uses mount namespaces to work around the lack of a sane config mechanism is not an answer.) This comes up every time we change the policy. Please note that the mechanism must be implemented in crypto-policies and/or the crypto libraries. We can't realistically add a configuration mechanism to each user of crypto, and even if we did, users wouldn't want to use such a mechanism.

Ideally, we'd also have per-program config that could be used to override config for specific applications, like mock or ftp or other things which need to interact with legacy stuff. (And no, the global hammer of setting host-wide policy is not an answer.)

The warnings: so far there's only the BPF-based tool that requires opt-in. Apparently not many people are using that. There's also the approach of setting the host-wide policy. From various reports, it seems to immediately "break the world", so I assume that not many people are doing that too.

You seem to think that people don't look at warnings in stderr. I assure you that this is not the case. For example: python3.10 introduced new syntax warnings (e.g. for invalid escapes likes \s) and deprecated various modules. Python emits DeprecationWarnings, by default to stderr, but they can be silenced or redirected. Those are visible to users, but also to developer doing package builds and running the test suite. People notice warnings and those issues were fixed very quickly. Note the following advantages: there were clear warnings ("Invalid escape … in file.py:line-nnn", and not something like "SyntaxError: can't load file"), thus relatively easy to figure out. It was possible to fix them one-by-one, because you could run the test suite and see warnings from your program but also all libraries recursively, if any. The whole thing was fairly painless for users.

The case of SHA-1 deprecation is technically very different, but in some ways it's also similar: something that is widespread used to work, and now will be rejected, and fixes in many many different places are necessary, some of them outside of user control.

The solution should also be similar:
1. warnings that are visible to users and maintainers, but don't break functionality.
2. the warnings must clearly indicate what, where, and why
3. a mechanism to silence the warnings or promote them to hard errors for development
4. a gradual move from opt-in warnings, through opt-out warnings, to outright failure when most cases have been fixed.

The case of SHA-1 is different from the Python case because we know that there'll be cases which will never be fixed and we'll need a mechanism to allow those uses indefinitely. Thus the need for a nice mechanism for overrides.

bz2064740 is an entirely different request, and no, I don't see an envvar-based solution that'd support user-defined policies, thus the (entirely unrelated to this request) cap-enabled wrapper. That I, as of now, don't intend to bring into Fedora.

Mechanisms to override cryptographic library defaults are something that cryptographic library defaults should provide to applications, and applications should be using armed with red banners, broken lock icons and asking user thrice whether they're OK being insecure, because crypto library API is the interface for applications to restrict/allow themselves from doing crypto things.

a gradual move from opt-in warnings, through opt-out warnings, to outright failure when most cases have been fixed

That'd be ideal, but I find it neither feasible nor useful to implement opt-out warnings since libraries don't have meaningful logging facilities, so what I'm offering to go from opt-in warnings to outright failures in two releases.

If, say, libreoffice legacy format saving or iPhone pairing mechanism would find themselves relying on OpenSSL SHA-1 signature, people will only notice when we move to 'outright failures' anyway. And for the rare dozen of cases when this output does go into something fragile, printing from a library will be immediately and rightfully called a bad idea, one we'd have to revert with apologies to everyone affected.

This was discussed during today's meeting:
* Proposal: approve the change as-is (with a plan to revert the removal in F38 once it's branched)
* AGREED: Approval rejected (+1, 4, 0)

I'll leave this open for a new approach.

Metadata Update from @zbyszek:
- Issue untagged with: meeting

4 days ago

Login to comment on this ticket.

Metadata