--On Monday, March 15, 2004 10:52 AM +0000 Ben Laurie <[EMAIL PROTECTED]> wrote:
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.
I know.
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).
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?
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
I have yet to be convinced of this.
Cheers,
Ben.
-- http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
