It is? How? Unless the committer signs (which ISTR was rejected as an option when I suggested it, so I'm assuming that doesn't happen), then they must be signed by the server - a successful attacker can therefore sign his modifications, too. Or am I missing something? (I don't use subversion yet, so forgive me if the answer is obvious).
We're talking about ensuring the integrity of the repository here, not whether malicious people can commit. With the repository and its dumps, everything is date-ordered. The revisions are sequential and the dumps only contain the changes for that particular revision. Once the changes are made, they can be signed by the server and rsync'd via a third-party 'secure' server (*only* adding the new revisions). In the event of an intrusion, we can use those read-only dumps to compare against our 'live' repository. Also, if a malicious set of commits occur, we can also *quickly* remove those as everything is identified by a changeset/revision number across the repository (again, not possible with CVS as it has per-file revnums).
We also have to address changes to a revision post-mortem (i.e. changing the log message), but that can be dealt with rather easily.
It is news to me that the board have expressed this view.
No, it's not official, but every time we have an intrusion, we have no useful mechanism of auditing the integrity of our CVS repository as people can modify the RCS files directly and that *has* been a concern brought up by the board on several occasions. With Subversion, it is possible to easily verify the integrity of the repository against backups. -- justin
