On Thu, Apr 7, 2022 at 9:06 PM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
>
> 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'm afraid not, because there's also a logging phase proposed,
one that shouldn't go to F36 and keeps the plan from shifting forward. Meaning:
F36: FUTURE update
F37: FUTURE update + logging
F38: DEFAULT update in rawhide only
F39: DEFAULT update that reaches release
hasn't really shortened.
> I don't think we want to drag this out *too* much.
And neither do we want to rush it.
The more ahead of the world we would be, the more work it entails for us,
so it's a balancing act.
> > > 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).
Noted, 4 system-wide changes =)
> > 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
