From: Michael J Gruber <git@drmicha.warpmail.net>
To: Junio C Hamano <gitster@pobox.com>, Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/2] Documentation/technical: signature formats
Date: Fri, 24 Oct 2014 17:36:19 +0200 [thread overview]
Message-ID: <544A71F3.1020607@drmicha.warpmail.net> (raw)
In-Reply-To: <xmqq7fzshqrb.fsf@gitster.dls.corp.google.com>
Junio C Hamano schrieb am 22.10.2014 um 21:02:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Various formats for storing signatures have accumulated by now.
>> Document them to keep track (and maybe avoid yet another one).
>
> I haven't looked at the description closely, but it is a good thing
> to describe signature in a tag and in a commit in detail, which we
> failed to do so far.
>
> The principle is essentially the same between the signature on a tag
> and on a commit: a detached PGP signature over the remainder of the
> object data is created, and then the signature is inserted into an
> appropriate place in the resulting object. That "appropriate place"
> is influenced by the type and nature of the object.
Yes, the detached signature can't easily be appended to a commit object
the way it follows a tag object. Conversely, signed tag could easily
look like signed commits do (sig in header), but that would require a
migration procedure.
> A mergetag is not fundamentally a "signature" in the above sense,
> though. It is just a dump of the object content in a regular object
> header field (hence indented by one SP), and its contents having PGP
> SIGNATURE is merely a natural consequence of the object recorded
> being a signed tag. So the description of it in the same place as
> description for signed tags and signed commits feels a little bit
> out of place, but I do not think of a better place to describe it.
I guess referencing the tag object (like other objects do) rather than
embedding it would have had its merits, but that is beating up a dead
horse. On the other hand, we could migrate to "mergetag sha1" rather
than "mergetag object foo" which is easily distinguished, but only
embedded objects are "safe" against non-aware gits.
> Thanks.
Thanks, Jakub and Junio.
I will correct the wording for the multiline header and put the mergetag
last to make it clearer that it's related but different.
Michael
next prev parent reply other threads:[~2014-10-24 15:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-22 15:16 [PATCH 0/2] document signature formats Michael J Gruber
2014-10-22 15:16 ` [PATCH 1/2] Documentation/technical: " Michael J Gruber
2014-10-22 16:57 ` Jakub Narębski
2014-10-22 19:02 ` Junio C Hamano
2014-10-24 15:36 ` Michael J Gruber [this message]
2014-10-24 17:10 ` Junio C Hamano
2014-10-25 8:30 ` Jakub Narębski
2014-10-30 10:19 ` Michael J Gruber
2014-10-22 15:16 ` [PATCH 2/2] Documentation/technical: document push certificate format Michael J Gruber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=544A71F3.1020607@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.