On Tue, 2025-10-21 at 20:47 +0200, Philipp Kern wrote:
On 2025-10-21 14:00, MOESSBAUER, Felix wrote:
> > Our assumption was, that a Debian source package is precisely
> > identified by its name and version, but this does not seem to be true.
> > Is this indeed not required by the policies, or are these findings
> > bugs?
At my work we identified these by dsc hash instead, because that's the
hash dictionary for all the other files. I think that's the right way
for all Debian artifacts.
That's also what we do if we have that information (e.g. from the apt
cache). However, unfortunately different checksums are provided / used
at various places:
- in apt _Sources files, we have md5 and sha256
- .dsc files usually have md5, sha256 and sha1
- snapshot uses sha1 (is that actually documented or an implementation
detail?)
Finding a .dsc file on the snapshot mirrors where we have name+version
+sha256 (from apt-cache) currently requires us to fetch all .dsc files
attached to the package, compute the sha256sum and compare it to our
local sum.
> We just found another package where the .dsc file is listed multiple
> times, this time semantically identical, but with an updated signature
> (same key, different timestamp). One of the artifacts is also found in
> the current bookworm release [3]. Adding the key owners in CC.
Snapshot by design is able to serve any content, any artifact can
change. For instance debian-security and debian proper are technically
separate archive instances and there is a copy process from security
to
the main archive. Sometimes that fails and a new dsc is signed for the
main archive upload. Most of the time we try to reinject the original
artifact though.
So yes, that can happen - especially if the archive has forgotten
about
the artifact (reupload of an old, removed version - even though that'd
be heavily discouraged) or if there are separate archives.
Thanks for this clarification. However, to me it looks like all these
packages are from the same archive "debian".