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
