Iustin Pop <[email protected]> writes: >> Yes, *BUT* currently the only tool that has these semantics is >> 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.
> Maybe I don't understand the disagreement here, but I don't see how > these two fields are tag2upload specific. I don't think that's what Ian is saying. I think they're saying that the semantics are specific to an automated upload service that acts on signed tags, which is different from a manual upload by the maintainer. > 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. The semantics are subtlely different. The field is defined to point to the signed tag that triggered an upload via an automated process. Currently, Policy says specifically one using the tag2upload protocol, but if there are other automated processes to act on signed tags in a similar way and produce the same artifacts, I can see the argument that this should be expanded. However, in your case, the field would instead point to the signed tag that you *manually* uploaded via some different process. This is *similar*, but it isn't the same thing. For example, your packages would then be false positives for a process that wants to check or otherwise manipulate all archive packages that went through the tag2upload server (as a security check, etc.). In other words, this field doesn't *only* carry the semantics that this package corresponds to a specific Git tag. It *also* carries the semantics that the package was prepared via an automated process based on that signed tag. It also implies a few other possibly-relevant things that your manual upload may not match, such as that the relevant annotated tag object can be obtained from the dgit-repos server. If we want a field that only means the former and not necessarily the latter, at least at first glance I think that should be a separate field so that the semantics are clear. Fields are relatively cheap; we can add more if we need to! -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
