Hi! On Thu, 8 Jan 2026 at 08:10, Ian Jackson <[email protected]> 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.)
