Re: Landing a larger-than-release change (distrusting SHA-1 signatures)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux