| 1 |
On Mon, Jun 4, 2012 at 4:41 PM, Brian Harring <ferringb@×××××.com> wrote: |
| 2 |
> |
| 3 |
> If that doesn't answer your question/concerns, be more explicit |
| 4 |
> please. |
| 5 |
|
| 6 |
How about a scenario: |
| 7 |
|
| 8 |
1. Gentoo dev commits a bunch of stuff to the tree. Top of tree is signed. |
| 9 |
2. Hacker commits something to the tree. Top of tree is not signed. |
| 10 |
No need for preimage attacks or whatever on sha1 - they just log into |
| 11 |
the server and do a git commit or whatever right into the tree. |
| 12 |
3. Gentoo dev commits a bunch of stuff to the tree. Top of tree is signed. |
| 13 |
4. Rsync mirror update happens - top of tree is signed, so update |
| 14 |
proceeds normally. |
| 15 |
|
| 16 |
If you go back and look at the tree you see a bunch of signed and |
| 17 |
unsigned commits. How do you easily detect how the unsigned ones got |
| 18 |
there (via a dev with a merge commit, or via other means)? Either way |
| 19 |
they'll be parents of merge commits - since merge commits have two |
| 20 |
parents - the pre-commit gentoo-x86 tree, and the incoming commits. |
| 21 |
|
| 22 |
Andreas - I'm pretty sure a merge commit still includes a tree. |
| 23 |
|
| 24 |
Rich |
Archives