Alexander Sosedkin wrote:
> That's a reason why my initial thread [1] has been named
> "Landing a larger-than-release change (distrusting SHA-1 signatures)":
> flipping the switch is the easy part, unfortunately.
IMHO, a change that breaks so many things that you expect it to take more
than 6 months to fix the breakage across the entire distribution is just
unacceptable to begin with and should just not be done altogether, ever. At
least not as long as it is expected to break so many things. Maybe in 10 or
20 years, you can even consider dropping SHA-1. The real world does not move
as fast as the progress in cryptanalysis, you just have to accept that.
Maybe it can work to distrust SHA-1 in some particularly security-critical
contexts, e.g., make RPM distrust SHA-1 signatures for packages installed on
the system (but not, e.g., in a mock chroot targeting some older RHEL!) by
default, with an easy way to change that default (I am thinking of something
like "echo 'trust_sha1_sigs 1' >/etc/rpm/macros.trustsha1"). But disallowing
SHA-1 systemwide, with no regards to what the actual application is and what
level of security it provides, is just insane, and will just lead to
applications bundling their own SHA-1 implementation and possibly even their
own PGP signature implementation to work around your deliberate breakage.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
