Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > Junio C Hamano schrieb am 22.10.2014 um 21:02: >> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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. I do not see much point in doing such "migration", though. Whom is it supposed to help? >> 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. Such a format would have defeated a major point of mergetag. The header embeds the data, not a reference to an external object, so that the resulting merge commit can be validated without having an extra tag. The resulting repository does not have to keep a tag reference that nobody else is interested in, which is an added bonus. I however agree that if there were no downside having to reference and maintain an extra tag, having the data there (i.e. the real "mergetag" format) and a reference there (i.e. your alternative) would have the same level of security and assurance. That tells us that whatever is on "mergetag" is "not fundamentally a signature", as I said already, doesn't it, though? The description of "mergetag" in this document should not have to change, even when the mechanism used to sign underlying "tag" objects were to change in the future. For that, you can just say that it is just a bit-for-bit copy of the tag object that was pulled into the history with the merge. The way how bits from the tag object are recorded there needs to be described. What the bits mean (e.g. it has a detached GPG signature over what appeneded in what way) does not need to be (and I think should not be) repeated in the description of "mergetag". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html