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