On Tue, May 26, 2015, at 15:25, Vincent Bernat wrote: > ❦ 26 mai 2015 14:38 -0300, Henrique de Moraes Holschuh <h...@debian.org> > : > > >> A solution to this without history rewriting is to tag the commits you > >> want to sign. > >> > >> You could tag any commit at any time, and sign that tag. Impractical if > >> you want to retroactively sign a huge swathe of commits, but not bad if you > >> want to retroactively sign a handful of releases, say. > > > > Just remember to have a meaningful comment/message for the signed tag, > > because it can be duplicated/renamed at will. > > Doesn't it cover the SHA1 sum?
The sha1 (lets call it object hash) covers the entire object, including its signature. The signature covers the contents of the object. For tag objects, this does include the tag message, as well as its author, commiter and date, and the object hash of the commit the tag object points to. However, the name of a tag is not part of the tag object, so it is not covered by either the hash, or the signature. It works just like a branch name, and therefore it is just a "reference". git does not have "signed references" yet, AFAIK. So, your scripts better not trust that a tag which is named 'v1.3.5' actually points to version 1.3.5 *just because* that tag was signed. Instead, they would have to ensure the tag is signed, that the signature is valid and made by the expected key, and that the tag message contents are 'Release v1.3.5', for example. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh <h...@debian.org> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1432736017.3246921.279379969.107d3...@webmail.messagingengine.com
