| 1 |
On Sun, Sep 14, 2014 at 10:56:33PM +0000, hasufell wrote: |
| 2 |
> W. Trevor King: |
| 3 |
> > On Sun, Sep 14, 2014 at 10:38:41PM +0000, hasufell wrote: |
| 4 |
> >> So we'd basically end up using either "git cherry-pick" or "git |
| 5 |
> >> am" for "pulling" user stuff, so that we also sign the blobs. |
| 6 |
> > |
| 7 |
> > Rebasing the original commits doesn't protect you from the |
| 8 |
> > birthday attach either, because the vulnerable hash is likely |
| 9 |
> > going to still be in the rebased commit's tree. All rebasing does |
| 10 |
> > is swap the committer and drop the initial signature. |
| 11 |
> |
| 12 |
> According to Robin, it's not about rebasing, it's about signing all |
| 13 |
> commits so that messing with the blob (even if it has the same |
| 14 |
> sha-1) will cause signature verification failure. |
| 15 |
|
| 16 |
All cherry-pick and am do is apply one commit's diff to a different |
| 17 |
parent. Changing the parent hash (which is stored in the commit body |
| 18 |
[1]), so old signatures won't apply to the new commit. If there have |
| 19 |
been other tree changes between the initial parent and the new parent, |
| 20 |
the tree hash will also change, which would also break old signatures. |
| 21 |
None of that has anything to do with a malicious blob being pushed |
| 22 |
into the tree disguised as a same-hashed good blob. Such a blob will |
| 23 |
*not* break any signatures, since GnuPG is *never hashing the blob |
| 24 |
contents* when signing commits [1,2]. You're only signing the commit |
| 25 |
object, not the tree and blob objects referenced by that commit. |
| 26 |
|
| 27 |
Cheers, |
| 28 |
Trevor |
| 29 |
|
| 30 |
[1]: http://article.gmane.org/gmane.linux.gentoo.devel/77537 |
| 31 |
[2]: http://git.kernel.org/cgit/git/git.git/tree/commit.c?id=v2.1.0#n1076 |
| 32 |
|
| 33 |
-- |
| 34 |
This email may be signed or encrypted with GnuPG (http://www.gnupg.org). |
| 35 |
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy |
Archives