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

-1 same reason as @decathorpe

(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)

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.

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.

Based on the output from today's FESCo meeting, there's an interest among the group to potentially keep SHA-1 support forever but provide some kind of log or deprecation warning when it is being used. Is this possible?

Based on the output from today's FESCo meeting, there's an interest among the group to potentially keep SHA-1 support forever but provide some kind of log or deprecation warning when it is being used. Is this possible?

@asosedkin can you comment on this?

there's an interest among the group to potentially keep SHA-1 support forever

SHA-1 as a hash function isn't going anywhere yet.

Trusting signatures using SHA-1 support forever is certainly not reasonable,
since their security relies on collision resistance.
SHA-1 is already broken on that front, and in the following years
it'll become outright trivial to crack it.
Algorithms have to be and are constantly phased out.
Nothing would trust signatures using MD5 anymore.
Cryptographic libraries aren't even offering MD4 hash implementations anymore.
The cycle is inevitable.

but provide some kind of log or deprecation warning when it is being used.
Is this possible?

This is resurfacing a lot. Everything is possible.

Logging by writing to some file descriptor from openssl itself
has been discussed many times and
is considered a bad idea by both me and openssl maintainers.

A non-invasive tool to do such logging opt-in [1] [2] using BPF and USDT probes
has been provided since Fedora 36
and is mentioned in the change testing instructions.

Auto-installing and auto-enabling such a tool is doable,
and will cost us a lot of hassle (introducing packages, dropping packages).

In any case, I predict people not noticing and not reporting issues
until the operation in question becomes blocked for real,
and any kind of such logging will go largely unnoticed.
After all, your iPad pairing worked fine,
and your legacy document has opened OK in Libreoffice,
why look at logs and report anything?
Looking at logs despite everything working fine and
trying to remember what exactly have you been doing last Thursday to trigger it
is already a very explicit decision to be made by the user.
Having a logging tool preinstalled and running on each and every system
just for the benefit of such highly motivated users sounds very overkill to me.

But since Fedora has spoken that the current course isn't considered OK,
I'll consider such options when reproposing,
if only for little benefit other than convincing FeSCO.

[1] https://gitlab.com/redhat-crypto/fedora-sha1sig-tracer/-/blob/main/sha1sig-tracer
[2] https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer

I wonder, if you're worried that deprecation log messages would basically end up in /dev/null, would it be possible to integrate this with abrt, instead?

I mean ... we already have a tool for problem reporting that's installed by default (and shows desktop notifications when something happens), why not use it?

I'm afraid I don't have experience with abrt. Could you match me up with somebody who can triage the reasonability of this approach?

abrt: I think it's not a good fit at all. Currently abrt triggers on coredumps registered by system-coredump, and in this case we are not planning to make the programs crash, so this would require growing completely new functionality in abrt. Abrt hasn't been very actively developed in recent years, so this doesn't seem feasible. (Or even desirable.)

normal logging: I don't quite understand the big push against this. All kinds of programs log, and I regularly get requests from developers to resolve issues about unnecessary or erroneous logging in my packages. Clearly, quite a few people look at the logs. The mechanism is simple for developers, simple for users. I don't see why openssl couldn't log nicely that "Warning: SHA-1 signature for Entity Foo was called by program frobnicator by user jane. SHA-1 use is deprecated, see https://fp.o/wiki/Something for info" cannot be generated. Such a log entry should be clear enough for users and developers even if the user doesn't remember what exactly they were doing when it was generated.

bpf-based tracing: I'm certainly not advocating for this tool to be installed by default. I think it's a nice development tool, but I'd be against installing a system-wide tracing tool essentially for developer convenience. It feels risky (e.g. from privacy point-of-view, just explaining to users what it is and what is does is would be a chore) and in general too much for this purpose.

Tagging this as stalled. What do we need to unstick this one way or another?

This one is, indeed, stalled and the whole plan will have to be postponed. On my end, the rough plan I envision is resubmitting fundamentally the same proposal, but after hunting for bugs using mass rebuilds, after holding more test days and targeting some later releases. As for logging, I don't feel ready to convince openssl maintainers to add logging, though whoever wants to is free to try.

Given @asosedkin's most recent comment, I'm going to process this as rejected, unless someone objects today.

I'm adding pending announcement again. AFAICS, this was never announced.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RNJZUX3ZI34DIX6E4PVDKYQWCOFDQ4UY/