Hi Brane, i didnt get you. How can the server admin modify the content if contents are signed? Let me give a scenario, suppose we implement Public Key Infrastructure in SVN, where each client generates its private key and public key and registers this public key with the server so that anyone can access the public key to verify the contents.
Suppose algorithm works in this way. 1. Client computes hash of (contents concatenated with some revision properties), then sign this hash with its private key and sends this signed hash with the contents and revision properties. 2. So, now if server modifies any content, server dont know the private key of client, so server cant generate valid signed hashed. 3. Hence i agree with, server can put some garbage data. But server wont be able to do false accusation on some other clients. (Like in current SVN, server can change the name of client in log files, and it can accuse some other client for that particular commit. 4. But after implement PKI, server cant accuse another client. It just can currupt data, which can be determined too at the time of verification of signed hash using public key. Regards, Ruchir Arya > > If your server administrator is not trustworthy, then no amount of > signing is going to help. Anyone with direct access to the repository > storage (which a server admin will have) can modify revision contents > even if they're signed; no cryptographic signature is proof against > attack. > > > then there is a problem. Is there any future possibility to implement > > digital signing of changeset to achieve integrity and non repudiation? > > My focus is to implement some of the security related features in svn. > > Subversion's repository backend already goes a good way towards ensuring > integrity: the client provides cryptographic hashes of all committed > data and the server checks them before committing, and the reverse > happens during checkout/update. The server also stores hashes for > certain metadata (although not all; there's room for improvement here). > > Non-repudiation is a lot harder to achieve because it's not enough to > control the server, you also have to prove that every client making > commits is free from malicious software that could be inserting > backdoors at the source of the commit. > > -- Brane > >

