Lucas Nussbaum writes ("Re: Include git commit id and git tree id in *.changes
files when uploading? [and 1 more messages]"):
> On 08/01/26 at 11:12 +0000, Ian Jackson wrote:
> > using only the actual source coce from git, was the vector used for
> > the most serious and successful attack we have faced in many years.
>
> I think that you are arguing against using tarballs in general, while you
> should really be arguing against using tarballs like GitHub "releases"
> tarballs that are generated in an opaque way.
Is it possible to tell easily whether a "release" on (say) github is
such a tarball? I don't think I know how to do so.
I think you're right about tag tarballs (which I think have a
different URL). I think this distinction is rather hazardous becaue
it would be easy to use a non-git-archive tarball by mistake.
Instead of such guesswork (and opportunity for slips or confusion by
the Debian maintainer), if tarballs are to be used at all, the right
approach must surely be to *check* that the contents are as expected.
One way that could be achieved is:
1. Use an upstream tarball as your orig.
2. Base your git *entirely* on upstream git
(so *don't* gbp import-orig, but maybe do `gbp import-ref`).
3. Upload with dgit (or, tag2upload when pristine-tar is supported).
If the orig tarball is not identical to git, the source package won't
be identical to git either, and dgit push would then detect the
discrepancy between git and source package.
Of course this workflow is only suitable if the tarball is expected to
be from git archive and therefore be identical to upstream git. It
won't work for projects that use autotools `make dist`, for example.
I still think a workflow based entirely on git is better; it's
certainly a lot simpler.
The use of a tarball (and pristine-tar) to smuggle a git commitid from
the upstream git forge, through the maintainer's machine, through
salsa, through the archive, to your audit system, is a startlingly
complex overall system architecture. (NB I'm not saying that this is
your fault! But one of the git trasnition's project's goals is to
make things like this simpler.)
> Tarballs like GitHub tags tarballs that are automatically generated are
> not really less trustworthy than using the git repository directly. Of
> course one needs to trust the hosting provider, but that's also true
> when using git (the hosting provider could forge additional commits to
> inject vulnerabilities).
The git protocol does provide more opportunity for detection:
depending on the git workflows in use, and the nature of the attack,
this might show up as a non fast forward update somewhere.
But I do agree that this is very much a secondary benefit.
Regards,
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
