Hi! > > Are you aware of any attempts to integrate this into dpkg-buildpackage > > toolchain so systems that build .deb packages can have that metadata > > field universally and not just via official Debian uploads via > > tag2upload? > > If you want to actually be able to use that for audit purposes, you > might not want to work with the maintainer-specific mess that Salsa is.
Gunnar already posted a good reply, but let me add that there are a lot of packages on Salsa that are well maintained and where reading and verifying changes is easy. For the packages that have inconsistencies Salsa is still useful - there is just more work in figuring out what changes were done and why. In any case Salsa with rich git history is way more useful than looking at just the deb-src package. > Only debian/ or complete sources? > debian/patches/ or patches applied? > One git repository per package, or 1k packages in one git repository? > The contents of a git tag/commit does sometimes not match the > contents of the package in the archive with the matching version. > And a git repository might disappear, or the commit might disappear, > or the commit was never pushed anywhere. Yes these things can happen, and they add the amount of work needed to audit, but does not render it useless. For example in https://optimizedbyotto.com/post/xz-backdoor-debian-git-detection/ I noticed that the xz-utils version 5.8.1-2 debian/ contents uploaded to Debian wasn't exactly the same as what was pushed to git, but because Salsa has rich context, I could figure out the likely cause easily and see it was not malicious. > The proper solution would be if we had the git trees in the archive, > in a modern setup where the buildds are integrated in the git hosting > runner infrastructure so that the git CI tests the actual packages. > > But until then using tag2upload for your packages might be the best > option for that purpose. Yes, using tag2upload will prevent git and archive contents from diverging. Hopefully tag2upload also adds support for upstream tags and pristine-tar so signed tags and detached signatures can be uploaded to Debian (#1110269, #1106071), and hopefully uscan v5 templates add support to downloading git tag signatures and detached .tar.gz.asc type signatures as well (#1118381, #1118383). There are many things still to fix, also the git CI tests you mentioned above are not checked (#1111331). Using tag2upload now or in the future isn't conflicting with the desire to have git tag object/tree metadata in the upload. Also note that tag2upload is specific to Debian. My original proposal that started this thread was: > Otto: > To be better able to audit the software supply-chain I have been > thinking that we should have more git info in the changes file, namely > the git commit id it was generated from, and just in case also the git > tree id as well. Your response "you might not want to work with the maintainer-specific mess that Salsa is" to this assumes only the Debian Developer / Maintainer context which I didn't write anything about in my suggestion. There are a lot of companies that use Debian that have their additional internal or 3rd party repositories etc. Having a generic metadata field to track the git tag object and tree ids and tooling to populate those fields (e.g. dpkg-buildpackage) would help anyone anywhere audit what version of source code was announced as being used to build something, and then the auditing tools can incorporate that into their analysis to make pinpointing what stage introduced inconsistencies faster.
