Hi, > 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
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. > Lucas: > 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 ] +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.
