1 |
On Mon, Jun 4, 2012 at 4:48 PM, Rich Freeman <rich0@g.o> wrote: |
2 |
> When I do a cvs commit, I don't check the logs to make sure the last |
3 |
> 25 commits all look valid. So, why would I expect others to do any |
4 |
> differently in git. I make my changes, I run a git pull (bringing in |
5 |
> the hacked commit on gentoo-x86 master), and then merge/rebase in my |
6 |
> changes, signing my commit (which indicates that what _I_ just |
7 |
> commited is good, not that everything before is good). I am not the |
8 |
> one commiting in hacked files - they were there before I got there. |
9 |
|
10 |
If the tree was bad before you pushed, then it's not your fault the |
11 |
tree is bad. You're only responsible for the commits you bring into |
12 |
the tree, so if you're merging contributor's unsigned changesets, you |
13 |
merge them with a signature of your own. |
14 |
|
15 |
>> Of course, we'd have to make sure the tip of whatever is pushed is |
16 |
>> always signed, but the hook for that should be trivial. |
17 |
> |
18 |
> Yup, but the hacker wouldn't run the hook. |
19 |
|
20 |
If the hacker has unfettered access to the server where the repository |
21 |
lives, we probably have bigger problems, as they can get whatever |
22 |
rsynced to all our users. I guess we could have rsync process check |
23 |
that the cset it's about to push out to mirrors is signed? |
24 |
|
25 |
Cheers, |
26 |
|
27 |
Dirkjan |