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

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

 



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.

---

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




[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