On 2025-12-24 10:30:11, Ian Jackson wrote:
> Otto Kekäläinen writes ("Re: Include git commit id and git tree id in
> *.changes files when uploading?"):
> > 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.
>
> 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.
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
