On Tue, Sep 22, 2026 at 11:04:32AM +0200, Thomas Moschny wrote: > Am Di., 22. Sept. 2026 um 08:51 Uhr schrieb Zbigniew > Jędrzejewski-Szmek <[email protected]>: > > I think we should do this. If we accept the premise that the old > > hash cannot be trusted (i.e. that it's possible to craft a collision), > > then we want _all_ packages to use the new hash. If at least one > > package uses the "weak" hash, it becomes a potential attack vector. > > > > I think it'd make sense to apply this through a provenpackager. > > For each of the packages, fetch the sources from the cache, recompute > > the checksum, save new sources file. The commit should be done with > > '[skip changelog]' for packages with %autochangelog, and with no > > changelog entry for the rest. > > As you wrote, the old hash cannot be trusted; we cannot be sure that > the tarball downloaded during this process is still the 'correct' one. > Therefore, a simple download-rehash-upload cycle would only protect > against future attacks, not ones that have already occurred. Indeed, > it would merely mask the issue.
That is true (*, **), but it is still useful to do this. Basically, we're reducing the attack feasibility to the time between the original upload and now instead of between the original upload and next package version. (*) But actually, we might want to redownload the sources which are rehashed, and verify that they have not changed / that we have the correct copy. This would be more work, and probably cannot be automated in all cases, so I'm not sure if we'll do this. (**) Those weak-hash attacks are something of a theoretical possibility. To actually perform the attack, one would need to somehow push the replacement tarball to the store, which means either an attack on the infra or a compromise of a user account. In either of those cases, more dangerous attacks can be done then substituting a tarball. Zbyszek -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
