Re: Include git commit id and git tree id in *.changes files when uploading? [and 1 more messages]
Hi!
On Thu, 8 Jan 2026 at 08:10, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Gioele Barabucci writes ("Re: Include git commit id and git tree id in *.changes files when uploading? [and 1 more messages]"):
> > On 08/01/26 13:09, Simon Josefsson wrote:
> > > git checkout upstream
> > > git fetch up
> > > git checkout -B upstream up/v1.2.3
> > > git checkout debian/latest
> > > git merge upstream
> > > git diff debian/1.2.2-4..
> >
> > Isn't this the core of what `gbp import-ref -u1.2.3` does?
>
> >From the manpage, it looks like it, yes. TIL.
>
> I think this means that gbp import-ref could very well form part of
> the kind of workflow that we would recommend. So, jolly good.
>
> Of course I haven't looked into its handling of upstream tags etc. in
> detail, obviously, and I'm not sure why git branch formats (git
> packaging "workflows") it's compatible with. It's probably good with
> gbp pq, and might be compatible with dgit-maint-merge(7). I doubt it
> would DTRT for a git-debrebase user, but git-debrebase does about half
> of this job (the hard part) itself. So I'm not sure I'm in a position
> to advise about it.
If there are others who were not fully familiar with how
git-buildpackage option `upstream-vcs-tag` or command `import-ref`
works, and most importantly that this can be used to import both
upstream as a pure git commit/tag with the tarball produced by uscan
on top of it, I think you will find
https://optimizedbyotto.com/post/debian-packaging-from-git/ a useful
read as it explains a full example end-to-end with diagrams and
"screenshots".
This achieves the best of both worlds, and is compatible with what
Debian currently expects the resulting source packages to have. If the
upstream git release tag contents and the upstream release tarball
contents are identical, the upstream import commit that lands on the
`upstream/latest` branch will have no changes. If upstream git and
tarball did differ, it those differences will be visible in a single
commit, as demonstrated at
https://optimizedbyotto.com/post/xz-backdoor-debian-git-detection/.
That post is maybe a bit long, but hopefully an interesting read to
people interested in this topic and again visually tries to explain
clearly what is happening and what the person auditing will see where.
Note that in XZ Utils the actual backdoor was in test files that were
commited to git, and the Autotools change to compile them in was in
the upstream tarball. If Debian (or Fedora) only imports upstream git
contents, the attacker would most likely put both parts into git.
Stating that by not importing the tarball such attacks can be
prevented does not hold true. It was likely just an extra layer of
obfuscation. The attacker targeted Debian specifically and most likely
would have changed where the compilation changes are done if Debian
didn't import and use upstream generated Autotools files. (And I am
sure we all agree that the way Autotools regenerates so many files on
every release is an annoying for both quality and security issues.)
Reply to: