Re: Bug#1111127: ITP: golang-go.yaml-yaml-v3 -- YAML Support for the Go Language
Hi,
On Fri, 22 Aug 2025 at 13:59, Andrea Pappacoda <andrea@pappacoda.it> 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
Reply to: