1 |
On Mon, Jun 4, 2012 at 10:26 AM, Dirkjan Ochtman <djc@g.o> wrote: |
2 |
> On Mon, Jun 4, 2012 at 4:18 PM, Rich Freeman <rich0@g.o> wrote: |
3 |
>> How do you KNOW that the nearest signed descendant actually merged it? |
4 |
>> |
5 |
>> How do you know it wasn't added by a hacker? |
6 |
> |
7 |
> Because then the signature for the nearest signed descendant wouldn't |
8 |
> check out (unless it got hacked before he signed it, of course, but in |
9 |
> that case hopefully he wouldn't sign it...). |
10 |
|
11 |
When I do a cvs commit, I don't check the logs to make sure the last |
12 |
25 commits all look valid. So, why would I expect others to do any |
13 |
differently in git. I make my changes, I run a git pull (bringing in |
14 |
the hacked commit on gentoo-x86 master), and then merge/rebase in my |
15 |
changes, signing my commit (which indicates that what _I_ just |
16 |
commited is good, not that everything before is good). I am not the |
17 |
one commiting in hacked files - they were there before I got there. |
18 |
|
19 |
> |
20 |
> Of course, we'd have to make sure the tip of whatever is pushed is |
21 |
> always signed, but the hook for that should be trivial. |
22 |
|
23 |
Yup, but the hacker wouldn't run the hook. |
24 |
|
25 |
Rich |