Re: Guidance on version-identical source packages with different checksums
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
Reply to: