Russ Allbery wrote: > Git-Tag-Info: fingerprint=FINGERPRINT > Git-Tag-Tagger: Firstname Surname <email@address> > > and then Git-Tag-Info could be extended later using additional key/value > pairs to hold other information, use spaces or commas between attributes, > and so forth? For instance, that would let us add the date later if it > looked like that might be useful for some reason. > > That also allows the tagger field to be defined has having the same syntax > as Maintainer (or one of the other existing RFC-2822-style fields we > have), which I think increases the chances that parsers will get this > right.
I would suggest not thinking (or documenting) it as "Firstname Surname" for the normal reasons that apply when dealing with names. I would also ask that we have a clear definition of what can be in Git-Tag- Tagger now to ensure that we do not create yet another field where we end up with divergent ideas and implementations (#401452, #509935, #852677). Is it possible that we will ever have more than one signature attesting to an upload? If not, then let's define it as a single valued field and let's not impose quoting rules on the commas, parentheses etc that could easily be part of the name section. (I can't see a use for multiple signatures on the dsc, but I'd have said that about binary packages up until the reproducible builds project showed there is value for this for binary packages.) A more general question about these data -- is there enough information in the dsc and Git-Tag-Info/Git-Tag-Tagger to know *what* was signed and where it is located? I like that the proposal is to maintain the signer's information into the archive; I'd like also to know how to verify the signature later on should I wish to do so and I assume I need to know what to git clone and which tag to git tag -v. regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
