Hi, Le 2024-11-28 11:28, Alec Leamas a écrit :
Personally, the few packages I maintain are mostly repacked. Isn't there also value in storing the hash of the repacked tarball, the thing actually used?
Not much value, as both the hash and the data would be stored at the same place (git repo) if something is able to compromise the data not much more is needed to make the hash match the compromised data again. And anyway the (eventually signed) hash is in a .changes, and git itself already use (weaker, but good enough against data corruption) hashes to store things.
Signed commits/tags would help in that case but it looks like gbp import-orig doesn't support them on the pristine-tar branch. You have them on the upstream branch though, which is what actually matters.
Anyway in both cases it would be wise to compute the hash against the uncompressed (and normalized, timestamps ownerships order etc) .tar data, as only the delta (against uncompressed data) is stored and it is not guaranteed to get exactly the same compressed bit stream when rebuilding the compressed tarball on another system or an updated one.
Also FI and reference Gradle implemented something similar [1] for checking downloaded dependencies. Hashes are used only as last resort, when upstream provides no signatures, and signatures are much more convenient as they do not require to record a new hash with every release. Gradle also allows to store multiple hashes for the same dependency (group + name + version) which is useful with locally (re)built dependencies, and finding a matching hash allows an unsigned dependency where a signature would otherwise be required.
[1]: https://docs.gradle.org/current/userguide/dependency_verification.html
-- Julien Plissonneau Duquène
