On 15 September 2014 11:15, W. Trevor King <wk...@tremily.us> wrote: > All cherry-pick and am do is apply one commit's diff to a different > parent. Changing the parent hash (which is stored in the commit body > [1]), so old signatures won't apply to the new commit. If there have > been other tree changes between the initial parent and the new parent, > the tree hash will also change, which would also break old signatures. > None of that has anything to do with a malicious blob being pushed > into the tree disguised as a same-hashed good blob. Such a blob will > *not* break any signatures, since GnuPG is *never hashing the blob > contents* when signing commits [1,2]. You're only signing the commit > object, not the tree and blob objects referenced by that commit. > > Cheers, > Trevor >
And given that the method of "security" against attacks is established by a chain of custody from a signed commit, through multiple child unsigned SHA1 objects, having a parent being an unsigned commit is no *less* secure than having a tree or file blob being unsigned, it doesn't make perfect sense to me that "all" commits have to be signed. ( Because doing so doesn't give the benefit of security we think it does ). Thus, a "I signed this commit, establishing a chain of trust relying on SHA1 integrity to the previous signed commit" is all that seems truly necessary. Anything else is decreased utility with no increase in security. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
