Hi, On Fri, 22 Aug 2025 at 13:59, Andrea Pappacoda <[email protected]> wrote: > On Fri Aug 22, 2025 at 9:45 PM CEST, Otto Kekäläinen wrote: > > Uploads to the Debian archive, and what is stored in the Debian > > archive is still tarballs. Same applies for Ubuntu, and various > > tooling we have around uploads. Running dput to ftp-master, security, > > mentors, Launchpad etc will push tarballs and those checksums better > > match or uploads get rejected or the archive ends up having two > > versions of the same upstream tarball with different checksums. > > Sure. I was discussing about the security implications of pristine-tar. > I actually wrote a paragraph mentioning the archive, but deleted it for > the sake of brevity. > > I argue that even for this use case, pristine-tar does not make *much* > sense. Yes, it's convenient, but you can still download the orig from > the archive if it's already there.
Typically if I upload something to Launchpad, it is for the sake of testing that they build on all archs *before* upoading to Debian. Actually, when I think about it, almost 100% of the time when I am reviewing if an import was done correctly, it is because someone else did it and I am reviewing before upload. > Moreover, and I want to emphasize that **I'm not sure about this**, but > looking more closely at pristine-tar while integrating in t2u, I have > the impression that this point of keeping the hash equal to the one in > the archive does not hold; pristine-tar applies a binary diff *on top* > of what git-archive creates. If git-archive changes and generates > a slightly different tarball, pristine-tar will not help. And at that > point, pristine-tar isn't useful for this purpose. Good point, seems there are cases where pristine-tar is unable to function. Hopefully these could be documented somewhere so that people auditing imports can easily check if a finding is really suspicius or can be attributed to one of the know failure scenarios. ... > Sorry, my point wasn't clear. I mean that, *when using upstream vcs > tags*, pristine-tar isn't useful, etc. etc. > > For cases where upstream doesn't use Git, I'm a strong supporter of the > use of pristine-tar. I think it is still useful and you can do dual import. Debian does not have any tooling to check git tag signatures automatically or upstreamvcs remote matches, so right now basically almost all suppy-chain validation relies on tarball checksums. ... > I've actually seen the opposite in many projects! For example, mbedtls > ships huge generated test files in their release tarball, but not in Git > (even though they actually recommend me to use Git tags and avoid > tarballs). Or think of the various autotools-generated stuff, which is > absent in Git. Yes, that could happen too, but most of the time the release tarballs are announced as such and intended for users to consume. I think it is very rare for an upstream to produce tarballs and then tell users to avoid them. > In other packages, yes, the tarball contains extra things like > documentation or test files which would normally be downloaded > on-the-fly during build (which is of course undesirable). One such case > I personally maintain is muon, which has a simple script which > concatenates three tarballs into one: > https://salsa.debian.org/debian/muon-meson/-/blob/archive/debian/0.4.0-1/tools/ci/prepare_tarball.sh?ref_type=tags > > Different packages, different optimal choice! > > > For the time being, a tarball with files is the only common > > denominator across all upstream software. > > I fully agree with this statement. It is the common denominator. For > a high number of upstreams, though, it is far from the best option. > > Maybe it'd be better to optimize for the majority of upstreams > (promoting a Git-first workflow), at the expense of less common cases? > > On the topic of the Go Team workflow specifically, it should be noted > that for Go's dependency management tools to work, upstreams have to use > a VCS. I think what might be missing from this picture is the overall view of where Debian is as a project, what is the ideal situation and how we can move there without having a transition period that breaks/regresses supply-chain security. We should really write a proper design doc/plan, but a rough roadmap in my mind would be something like: If upstream is not git: 1. Use pristine-tar now: pristine-tar = True 2. Promote upstream to create OpenPGP keys and sign publish signatures. 3. Introduce a new file debian/upstream/origin that has each upstream import as a line with exact tarball url and sha256sum, so people can repeat the download and verify it, and tools like origtargz would complain if sha256sum is not matching. This would remove the current inherent source of variability that uscan currently has not checking that upstream tarball didn't change. If upstream is in git: 1. Use both now: pristine-tar = True upstream-vcs-tag = v%(version%~%-)s 2. Promote upstream to create OpenPGP keys and sign publish signatures and git tags. 3. Rename in Go tooling 'upstream' to 'upstreamvcs' to be aligned with git-buildpackage (https://github.com/Debian/dh-make-golang/pull/247) 4. Have git-buildpackage and other tools support upstream release git tag verification, and if upstream has no release tags then at least track that git branch shasums form a proper chain on top of previous import. 5. Have tools that detect and alarm on file modifications outside the debian/ subdirectory so that those upstream git release tags actually mean something, and stop breaking a potential future check by not modifying upstream source files in Go tooling (https://github.com/Debian/dh-make-golang/pull/248) 6. Potentially also record the upstream import git remote url and commit id in debian/upstream/origin 7. Stop using pristine-tar only when it has become obsolete and the supply-chain can be, and is by default, properly verified by git-buildpackage or other standard tools. Related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871806 uscan: (dpkg, git-buildpackage) accept/mangle/store signed git tags in cases where upstream does not publish detached sigs on tarballs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839866 import-orig: please make --upstream-vcs-tag=... verify tag signatures https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972273 gbp import-orig does not sign commits with GPG
