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 > > --- > > 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
