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)
> 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.
> A second Fedora change should be filed for visibility,
> but clearly stating this will not affect f38 released.
>
> Phase 3 ("Return of the Panik"):
> And then Fedora 39 comes, where the revert hasn't happened,
> goes through the whole release cycle,
> but this time the change goes through and reaches stable.
> Again, a system-wide change, a third one for the same thing.
>
> With the 37-38-39 numbers, that'd mean the change
> reaching the users in autumn 2023, with lead times of:
> ~ 3.5 cycles for the most proactive developers to see this thread and panic
> ~ 3 cycles for the testers to proactively report bugs (logging/opting in)
> ~ 2 cycles to address everything else coming from rawhide testing
> before it reaches stable by either
> switching to some other algorithm,
> making the users explicitly opt into trusting SHA-1 signatures somehow,
> or, in the most high-profile cases,
> having a widely publicised exception (and some plan for the future).
>
> Questions:
> * Do you find this smudging reasonable?
I think it's probibly the best we can do.
> * The usual tightening of the other less controversial algorithms,
> should it follow the same smudging/reverting plan
> since we're going through all that hassle anyway?
I don't think they would need to have this long a runway.
> * Does the 37-38-39 timeframe feel right?
> * Do I need to first run this contraption of a plan
> by FESCo or some other smart folks?
Well, I think run it by everyone on this list.
I don't think people will hold back. ;)
> * Is there a better signalling mechanism than filing 3 system-wide changes?
> * What'd be the right mechanism for others to take the wheel if everything
> goes sideways and the need arises to revise the plan mid-execution?
I wonder if it would make sense to have a checkpoint before the revert
in f38, and if things look substantually less broken than we fear, we
just don't revert it and let it go out in f38. But that might muddy up
the communications.
> Other kinds of input are, of course, also appreciated.
> Even the calls to magically attain the mutually exclusive goals
> of offering secure defaults while not breaking insecure workflows
> that don't offer actual solutions might serve as a useful mood check.
> I know it ain't the best plan. Let's figure out the right thing to do.
Thanks for taking input on this and being willing to work out the best
way forward.
kevin
signature.asc
Description: PGP signature
_______________________________________________ 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
