On Tue, 2025-10-21 at 20:47 +0200, Philipp Kern wrote: > Hi, > > 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?) - Source packages referenced in built_using only have name and version information, but no checksum (and they often cannot be found in the apt cache) 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". This can be checked with: curl https://snapshot.debian.org/mr/package/golang-github-grpc-ecosystem-go-grpc-middleware/1.3.0-1/srcfiles?fileinfo=1 | jq '.fileinfo' > If you are > supporting archives outside of Debian proper, you already need to be > able to handle changes in the files, I think. Yes, true. PS: These findings were made during the development of the "debsbom" SBOM generator for Debian [1]. This generator is specifically made for Debian systems to precisely track packages (including checksums) and dependencies (including built_using). Packaging debsbom is on our roadmap (only missing dependency in sid is python-spdx-tools ITP[2]) [1] https://github.com/siemens/debsbom [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088705 Best regards, Felix Moessbauer > > Kind regards > Philipp Kern -- Siemens AG Linux Expert Center Friedrich-Ludwig-Bauer-Str. 3 85748 Garching, Germany
