Hello,
On Mon 15 Dec 2025 at 08:26pm -08, Otto Kekäläinen wrote:
> In *.changes files we already have the Vcs-Git line as metadata
> showing where the packaging sources are maintained with an exact URL
> and a `-b <branch>` identified if the upload was not from the default
> branch.
>
> To be better able to audit the software supply-chain I have been
> thinking that we should have more git info in the changes file, namely
> the git commit id it was generated from, and just in case also the git
> tree id as well.
>
> The git commit id (`git rev-parse HEAD`) is derived from what the
> chain of contents+commit messages was, and the git tree id (`git
> rev-parse HEAD^{tree}`) is derived from the file contents, so we can't
> embed either into the packaging repository itself (e.g. as extra lines
> in d/changelog) as they would reference itself in a circular manner.
> They must be put in some file that describes the upload _after_ the
> final git commit was made, and I think the changes file would be
> ideal. It already has the Vcs-Git header anyway, and it is the file
> any system processing the upload will see and can then act upon as
> needed.
>
> Has somebody else already been thinking about the same? Do others see
> value in this?
As has been pointed out, tag2upload adds fields for exactly this
purpose. But as you said in another message, we might want to think
about adding fields like you propose for non-tag2upload uploads.
I think it would be most fruitful for you to wait a little while. I'm
saying this because the tag2upload beta is ending very soon. We have
stopped receiving bug reports that make us think "we have to fix this
before we can end the beta". We are just finishing up three remaining
issues.[1]
When tag2upload leaves beta, a lot of maintainers will switch over to it
for their uploads, so a lot of uploads will gain the metadata you want.
If tag2upload's metadata is present for an upload, it will be of better
quality that what you are proposing to add, because our design
guarantees certain properties back to the maintainer's signature.
I.e., the interesting cases for you will only be uploads not done with
tag2upload.
But it is hard to say yet what those uploads are going to look like.
Who won't switch to using tag2upload, and why? Once we know what those
uploads are like, you will be in a much better position to design
something.
[1] #1111548 (small), #1112106 (mostly done),
https://salsa.debian.org/dgit-team/dgit/-/issues/71
(pure sysadmin)
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature