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
On 23/12/25 at 13:03 +0000, Sean Whitton wrote: > Hello, > > On Tue 23 Dec 2025 at 01:31pm +01, Lucas Nussbaum wrote: > > >> Policy explicitly says that these fields must not be added except for > >> uploads processed by tag2upload. So a patch like this should not be > >> installed. > > > > What is the rationale for this? > > 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. 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
