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