Hi,

Context: discussion at https://lists.debian.org/debian-devel/2025/12/msg00127.html

Please consider making git-buildpackage emit Git-Tag-Info tags when
building a source package, similarly to git-debpush.

That provides an audit trail, making it easy to know which commit was
used when building a package.

Such a patch could be used as a basis:

diff --git i/gbp/scripts/buildpackage.py w/gbp/scripts/buildpackage.py
index 36ad8d02..733fe936 100755
--- i/gbp/scripts/buildpackage.py
+++ w/gbp/scripts/buildpackage.py
@@ -572,6 +572,10 @@ def main(argv):
                                         'GBP_BUILD_DIR': build_dir})
                      )(dir=build_dir)

+            if repo.is_clean()[0]:
+                dpkg_args.append('--source-option=-DGit-Tag-Info=tag=%s' % repo.head)
+                dpkg_args.append('--changes-option=-DGit-Tag-Info=tag=%s' % repo.head)
+
             # Finally build the package:
             gbp.log.info("Performing the build")
             RunAtCommand(options.builder,


Best,

Lucas

What is the rationale for this?

Lucas

Hello,

I should have spoken more precisely.
This is what it says for each field:

    Uploads not generated in accordance with the tag2upload protocol
    must not include this field.

The tag2upload protocol means what's documented in tag2upload(5).

Inclusion of the fields is a statement that that protocol was followed
for the upload.  So, inclusion of the fields implies that the upload was
initiated by means of an uploader-signed tag with certain metadata, and
an automatic auditing program could trace the upload back to that tag.
If we add the fields for any other uploads then an automatic auditing
process like that probably wouldn't be feasible.

[CCing Ian -- for context see #1123842.]

While this makes sense to me, I'll say the field should then never
have been called the way it is called now. Given its
tag2upload-specific, it should have "tag2upload" somewhere in the
name.

Best,
Chris

For reference the debian-policy bug that discusses Git-Tag-Info and
Git-Tag-Tagger is #1091868, and the latest version of the patch is
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1091868;filename=v4-0001-Document-Git-Tag-Tagger-and-Git-Tag-Info-fields.patch;msg=85

What kind of audit are you thinking about?

The information provided by Git-Tag-Info is that the source package was
generated from a given git commit. This could be true whether the source
package was generated by the tag2upload service, or whether it was
generated locally by the maintainer. So I don't see why that field could
not be generalized to locally-generated source packages.

If the goal is to audit uploads done via tag2upload specifically, one
could first look at which key signed the dsc file to filter out other
uploads.

[ Also, if it is generalized, the fingerprint part could be made
optional ]

Lucas

Lucas Nussbaum writes ("Re: Include git commit id and git tree id in *.changes files when uploading?"):

No, that doesn't make sense.

The primary point of Git-Tag-Info is to allow legacy systems that must
work with .changes files (such as dak) to find out which human
uploader intended the upload.  This is necessary with tag2upload
because the .dsc and .changes are signed not by the uploader, but by
the tag2upload service.

For a non-tag2upload upload, this information is simply in the
.changes signature and no additional field is needed.

gi-based systems can trace the git tags via the git information in the
git depository, which includes the uploader's tag, and for tag2upload,
the maintainer's signed tag for the version in question.  All of this
information is in git.

If you want to trace a source package from dsc back to git, you need
the Dgit field.  And the Dgit field *is* added locally by dgit push
(and dgit is very careful to check that what it writes in the Dgit
field is actually true: in partgicular that the referenced git tree is
treesame to the results of dpkg-source -x (without .pc directory)).

So, no, Git-Tag-Info ought not to be generated by human-driven upload
tools.

Ian.

Chris Hofstaedtler writes ("Re: Bug#1123842: Include git commit id and git tree id in *.changes files when uploading?"):

I hope my other mail makes clearer what this field is actually for.

The name was agreed in our (extremely public and highly visible)
negotiations with the ftp team, over the deployment of tag2upload.
The time to say that the name was wrong was then.  We definitely don't
want to change it now.

Ian.

Hi,

Also note that this was added to the policy in
https://salsa.debian.org/dbnpolicy/policy/-/commit/bb22500a28c3fca96847ebe81d7f151066f6c41b
by Sean himself 6 months ago, and he rushed to publish it today
immediately after writing the message stating that only tag2upload is
allowed to use this field "because policy says" without mentioning
that he actually wrote the policy and published it today. Yes, one
other person seconded it so Sean and Ian didn't dictate it fully on
their own, but still I find this style of argumentation intellectually
dishonest and I felt the need to highlight this to avoid the audience
from being misled.

+1

I think it is common sense that other tools can also use the fields
Git-Tag-Tagger and Git-Tag-Info as long as they follow the same
semantics. It would feel very odd if other tools would start using a
new field called e.g. `Git-Tag-Author` and `Git-Tag-Object` just for
the sake of not using the same names.

Bug#1123842 is a good idea and Lucas' rationale for it is perfectly
valid. There could be some benefits of doing this at a lower level
too, like by dpkg-source or dpkg-buildpackage, but it's fine to
experiment doing it in any tool. The end result is still the same and
any auditing tool can double-check if it is true or not, and if the
uploader even tried to use git or not, and that would be a nice
improvement over current state of things.

Hi,

I don't think that's a fair characterization of what happened around
Git-Tag-*.  If we are looking for people to blame, we should blame
people like me who now think it's a good idea to generalize the scope of
those fields outside of the tag2upload context, but did not follow the
tag2upload discussions closely enough to raise that point when it was a
good time to do it.

The discussion about generalizing those fields could move into a
debian-policy bug.

However, it might be worth experimenting a bit to understand if it's
really useful. One could build a git->dsc audit service by doing:
- for a given dsc, use the Vcs-Git field and clone the repository
- identify the relevant tag for the version to check (using
debian/gbp.conf's debian-tag option if it exists)
- build the source
- compare with what is in the archive

I wonder how many packages could already be checked like that, and how
many more an additional dsc field would add.

Lucas

Hello,

Thanks, Lucas.

All this discussion prompted me to look at policy.git and I saw that
there were a bunch of unreleased changes that should be pushed out.
I thought that the Priority field becoming optional was the more
important thing, actually.

Once a change is committed to policy.git it's basically already
official, and that happened weeks ago.

Interesting.  I would be interested to read the results of a survey like
that.

Otto Kekäläinen writes ("Re: Include git commit id and git tree id in *.changes files when uploading?"):
tag2upload.

This is because the semantics are:

 "The PGP signatures on this upload do not tell you which human
  made this upload.

 "Instead, if you need to know which developer made this change,
  use the information in the Git-Tag-* fields."

Any future tool that had similar semantics ought to use these fields.
But such a thing would be a centralised service, because its package
signging key would (i) not belong to a human (ii) have to be trusted
by dak.

Lucas Nussbaum writes ("Re: Include git commit id and git tree id in *.changes files when uploading?"):

It's quite sensible to think about expanding the usage of metadata
fields to other contexts with the same semantics.  But, I think there
is a misunderstanding about what those semantics are.  See above.

(Such a misunderstanding is hardly surprising given how complex
everything is nowadays, and no blame lies with anyone about that.)

Thanks,
Ian.

Just thinking outloud, and note I am definitely not up-to-date with the
whole discussions around tag2upload, but: wouldn't all packages using
git-buildpackage (and doing it correctly) pass this test?

I am somewhat sure all my packages (few, to be clear) do so.

regards,
iustin

Maybe I don't understand the disagreement here, but I don't see how
these two fields are tag2upload specific.

If I would do a manual upload, and add these two fields correctly, that
is, Git-Tag-Tagger: my name/email and  Git-Tag-Info: pointing to a
signed (by me) tag, I don't see how this wuold conflict with with the
meaning of the fields when filled by tag2upload. The signature on the
changes file would be mine, but that would be the only difference.

I.e., adding these fields for manual uploads (correctly), wouldn't break
the tag2upload protocol - it would cause a 2-step lookup of the signer,
but would point to the same signer.

What am I missing?

thanks,
iustin

Iustin Pop writes ("Re: Include git commit id and git tree id in *.changes files when uploading? [and 1 more messages]"):

If the archive accepted such an upload from you, you would be able to
produce confusing information about who did the upload.

Tooling that isn't a service like tag2upload ought not to add these
fields becase of the possibility that they would be wrong.

These fields don't add anything useful.

Ian.

also a metadata of "it was uploaded by tag2upload"?

I don't understand why the two are mixed (as opposed to a separate
Uploader-tool: tag2upload).

I think Git-Tag-Info is actually a useful tag, aside from the manual
upload. And I think that's what the discussion in the thread was.

We can already guess for gbp how the tag is named, but no other field
(than Git-Tag-Info) points to the exact tag, unambiguously.

I'm not asking for a change, I'm just highlighting that it seems we lost
an opportunity. Git-Tag-Tagger could well be specialized to tag2upload,
but Git-Tag-Info or an equivalent could be generalized.

Again, I haven't followed the discusson, so this is just a remark, not a
request for change.

regards,
iustin