On 12/01/26 at 13:21 +0000, Ian Jackson wrote:
> 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.
Yes, by looking at what uscan ends up using as the source for the
tarball it downloads.
Tarballs that are auto-generated from tags or commits match:
https://github.com/USER/PROJECT/archive/refs/tags/vVERSION.tar.gz
(example:
https://debaudit.debian.net/orig-check/result/0001bd63f4bfad49838599994fc2799da1060441a8c66ff657c03246397da9ec#uscan
)
or https://api.github.com/USER/PROJECT/tarball/refs/tags/VERSION
(example:
https://debaudit.debian.net/orig-check/result/00388306fb91115b9b689652ed0304855751c89e59b47208d2e4ee44348774b4#uscan
)
or they use uscan's git mode with a tag or a commit, like
https://debaudit.debian.net/orig-check/result/0012e5c747a0f903f4b0d296ed277cb0135f212be114e1e198fe8c9ce3a7598e#uscan
On the other hand, URLs that are manually generated look like:
https://github.com/USER/PROJECT/releases/download/RELEASE_IDENTIFIER/ASSET_NAME
Example:
https://debaudit.debian.net/orig-check/result/87f0db65eab5054173057b9bf90b650175cd5fbce6a7917502320a7106bc5fc6#uscan
In practice, GitHub has the concept of "releases" and "releases assets".
If you look at
https://github.com/tukaani-project/xz/releases/tag/v5.8.2, there's a
"Source code (tar.gz)" link that is the auto-generated one, and a
"xz-5.8.2.tar.gz" one that is the manually-generated one, provided as a
"release asset" (and used by the debian package).
It would probably be a better practice if the upstream developer
gpg-signed the auto-generated tarball.
All of this is specific to GitHub of course.
> 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.)
Well the git commitid is not required in my case -- it's just nice
additional information to debug discrepancies.
Lucas
