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 [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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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
