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

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

 



On Wed, Mar 23, 2022 at 12:51 AM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Mar 8, 2022 at 1:40 PM Alexander Sosedkin <asosedkin@xxxxxxxxxx> wrote:
> >
> > Hello, community, I need your wisdom for planning a disruptive change.
> >
> > Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
> > Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> > I believe we should start planning
> > for the next cryptographic defaults tightening.
> > And next time it's gonna be even more disruptive because of SHA-1 (again).
> >
> > SHA-1 is a hash function from 1995,
> > which collision resistance is no longer to be relied upon for security [1].
> > At the same time, it's not like software has successfully migrated off it,
> > not even close.
> > It's not a question of "if" the world should migrate from it,
> > sooner or later we must part ways with it.
> > (Technically, some acute energy crisis or a collapse of civilization
> >  forever raising the costs of computations thousandfold would also do,
> >  but let's agree that migrating to a more modern hash is the way =)
> >
> > We've been disabling it in TLS, but its usage is much wider than TLS.
> > The next agonizing step is to restrict its usage for signatures
> > on the cryptographic libraries level, with openssl being the scariest one.
> >
> > Good news is, RHEL-9 is gonna lead the way
> > and thus will take a lot of the hits first.
> > Fedora doesn't have to pioneer it.
> > Bad news is, Fedora has to follow suit someday anyway,
> > and this brings me to how does one land such a change.
>
> Given that RHEL 9 already switched the crypto-policy defaults, and we
> presume that future RHEL releases will not deviate from that, is this
> change already made in ELN?  I honestly can't tell because it looks
> like it is, but I don't see any conditionalization in the spec file
> that would lead me to believe the same default isn't already flipped
> in Rawhide.  That leaves me wondering what needs to be changed and
> where at this point.
>
> josh

No, it's neither in ELN nor in Rawhide yet.

> > Fedora is a large distribution with short release cycles, and
> > the only realistic way to weed out its reliance on SHA-1 signatures
> > from all of its numerous dark corners is to break them.
> > Make creation and verification fail in default configuration.
> > But it's unreasonable to just wait for, say, Fedora 37 branch-off
> > and break it in Rawhide for Fedora 38.
> > The fallout will just be too big.
> >
> > Maintainers need time to get bugs, look into them, think,
> > analyze, react and test --- and that's just if it fails correctly!
> > Unfortunately, it's not just that the error paths are as dusty as they get
> > because the program counter has never set foot on them before.
> > Some maintainers might even find that
> > picking a different hash function renders their code non-interoperable,
> > or even that protocols they implement have SHA-1 hardcoded in the spec.
> > Or that everything is ready, but real world deployments need another decade.
> > Or that on-disk formats are just hard to change and migrate.
> > Took git years to migrate from SHA-1, and some others haven't even started.
> > There are gonna be investigations, planning, exceptions, upstream changes,
> > opt-out mechanisms, arguing, compromises, waiting out, all kinds of things.
> > It's gonna be big. Too big for a single release cycle.
> >
> > ---
> >
> > But how does one land something and give the distribution
> > the extra cycles needed to react? That's not really clear to me.
> >
> > An obvious thing is to announce it in one cycle and land in another one.
> > The downsides are well-documented
> > in "The Hitchhiker's Guide to the Galaxy":
> > announcements are one weak measure, and then it's too late.
> >
> > A second scheme I can come up with is a "jump scare".
> > Break the functionality in Fedora 37 Rawhide,
> > make most of the affected people realize the depth of the problem,
> > then unbreak it. Break again for Fedora 38 and never fix.
> >
> > This could also be extended into "let one stable release slide'.
> > Break in 37 Rawhide, unbreak on branched off 37,
> > but never in Rawhide.
> >
> > But these are all rather... crude?
> > Sure there should be better ways,
> > preferably something explored before.
> > I'm all for pulling this tooth out smoothly,
> > but I need hints on how to do it.
> > I hope that together we can devise a better plan than these.
> >
> > So, how does one land a change that's bigger than a release cycle?
> >
> > [1] https://eprint.iacr.org/2020/014
> > _______________________________________________
> > 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
> _______________________________________________
> 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
_______________________________________________
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