c) You appear to be assuming daily snapshots maintained forever in your story - if so, how do you deal with network problems and the like? How can you tell a commit that didn't make it to the "secure" server because of a network problem from one that the attacker injected?
I think you're misunderstanding here. After every commit, an incremental backup containing that revision is generated. It'd then be copied over to a 'backup' site. There is no reason to re-dump the repository every day as that'd be just too big. If a commit is 'missed' due to an attack or whatnot, it'd be obvious because that particular revision number will not appear.
This is not like CVS where the prior history can be directly modified by tweaking the RCS files. For CVS, there is no concept of incrementality - the RCS files just aren't stable enough.
I'd suggest seeing minotaur:/x1/svn/hot-backups for an idea as to what we're doing right now. (We have yet to digitally sign anything though.)
In the solution you've rather vaguely outlined, after a server compromise I find myself checking a bunch of commits signed by the compromised server and then making some other vague assumptions I'm not sure I understand to convince myself that they were pre-compromise signatures. I don't feel like my security has been improved. Possibly a clearer explanation is all that is required, or maybe a rethink. I can't tell at this stage.
I think you're missing that the incrementality causes us to believe the pre-compromise signatures (as the backup can be done in such a way not to modify already existing files). Remember, everything is uniquely ordered in Subversion. If you also don't trust a hot backup, you can also burn those dumps to a 'permanent' media like a DVD-R to later verify it. But, once revision 1 is committed, that's revision 1 forever - it's immutable once it's in the repository. If it *has* changed, that's evidence of a compromise. -- justin
