Re: tag2upload should record git tag signer info in .dsc [and 1 more messages]
- To: email@example.com,
- Cc: firstname.lastname@example.org, email@example.com
- Subject: Re: tag2upload should record git tag signer info in .dsc [and 1 more messages]
- From: Ian Jackson <firstname.lastname@example.org>
- Date: Mon, 22 Jul 2019 19:55:26 +0100
- Message-id: <[🔎] email@example.com>
- In-reply-to: <firstname.lastname@example.org>, <handler.932753.B.email@example.com>
- References: <firstname.lastname@example.org> <handler.932753.B.email@example.com> <firstname.lastname@example.org> <18ECEC09-EF0B-439E-A329-6739C3572A0C@kitterman.com> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20190722144659.GB25690@home.ouaza.com>
Hi. I am consulting on the name and syntax of a new field I intend to
put in .dsc's.
This is for our tag-to-upload service, as described here:
The tag2upload service will take a signed git tag, and verify it
against the Debian keyrings and dm.txt. It then turns that into a
source package which it signs with its own key.
That means the original "uploader" information (ie the identity of the
person signing the git tag) is not any more present in the source
package. To rememdy that I propose the following new field:
Git-Tag-Info: FINGERPRINT Firstname Surname <email@address>
The parsing rules are: the first word is the fingerprint entirely in
hex. The rest is from the tag's "tagger" line (and may not match).
Consumers which want to know which OpenPGP key ws used should use
FINGERPRINT. Consumers which want to send email should use the RHS.
This syntax does not contain the signature date, nor the tag message,
nor any OpenPGP cert name. An OpenPGP cert name would be a pain to
provide in a securely meaningful way. The tag/signature date is not
that important I think (and might be annoying to extract from gpgv).
I think consumers won't need that information.
It also eldides some tag2upload-specific metadata, info about git
branch formats, and so on, but I think a .dsc consumer does not need
If you are likely to have an opinion, please reply as soon as you
can, since I hope to do the engineering work to make this thing
production-ready as soon as the relevant design reviews etc. are done.
If it will take you more than a few days to comment, please reply
right away with a holding mail saying when you hope to find the time
to write a substantive reply.
 The service is still a prototype, but will hopefully be deployed
soon, after some review, privsep work, integration discussions, etc.