I don't see how this defends against a malicious user that has owned the server for long enough for his changes to have been rsynced to the "secure" server?
Because it'd be read-only? That is, the changes won't be on the 'secure' server (i.e. they can't modify things *before* the box was compromised). Once it's compromised, sure, the malicious user can do 'bad' things, but, that's true with any system. Digital signatures by a committer don't add any protection here, either. Those compromised committers can do bad commits, too. However, once the malicious commits are identified, they can be easily rolled back and/or removed from the repository...
Do you have a suggestion here?
I have yet to be convinced of this.
I'm just not sure what you're looking for here. CVS offers *nothing* in the way of integrity checking. Subversion at least gets us moving in the right direction. I think you're underestimating the issues we have auditing our CVS repository. *shrug* -- justin
