On Wed, Apr 6, 2022 at 1:00 PM Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > > > Dne 08. 03. 22 v 19:40 Alexander Sosedkin napsal(a): > > 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. > > > Alexander, > > Could this be enabled in ELN? This is not really question but > suggestion. It is unfortunate, that ELN, while intermediate step for c9s > does not have this enabled yet. > > For example, we are working on Ruby 3.1 for c9s [1] just to figure that > while everything just works in Fedora/ELN, it does not work in c9s. > Maybe working with ELN would make the migrations easier also for Fedora. > > > Vít It's on my plans, but it'd take some time as it's not trivial. > [1] https://gitlab.com/redhat/centos-stream/rpms/ruby/-/merge_requests/10 > > > > 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. > > > > --- > > > > 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
