Re: Upstream tarball hashes: debian/upstream/*SUMS
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
Reply to: