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 <kevin@xxxxxxxxx> 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 don't think we want to drag this out *too* much.
> > 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"):
> > 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?
Please just file a late change for F36. We can then manually link the
same page into F37 and F38 (or even F39 if appropriate).
> 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.
Seconded. Thank you.
Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
