That link should be: http://svn.apache.org/repos/asf/subversion/trunk/notes/changeset-signing.txt
And you should presumably be working off trunk as well. Mark On Mon, Aug 3, 2015 at 3:56 PM, Ruchir Arya <[email protected]> wrote: > Hi Brane, > > Since last few days i am going through the document to implement changeset > signing. The link is given below: > > http://svn.apache.org/repos/asf/subversion/branches/master-passphrase/notes/changeset-signing.txt > In this document, i don't understand what is the meaning of the statement > given below. > "the client could silently retry the txn-commit if HEAD changed from the > time when the commit txn was created." > How can a client silently retry the transaction-commit or zombie > transaction? Which command can be used to do that? > Additionally, can changeset signing be applied to SVN the way it has been > proposed in this document? > > Thanks, > -Ruchir Arya > > On Monday, June 8, 2015 at 4:11:27 AM UTC-4, Branko Čibej wrote: >> >> On 08.06.2015 04:19, Ruchir Arya wrote: >> > Hello everybody, >> > >> > I am new to SVN development. I have a question. Why is there no >> > implementation of changeset signing in subversion? Suppose if the >> > root/admin (who maintains repository) is not trustworthy, >> >> 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 >> >> -- Thanks Mark Phippard http://markphip.blogspot.com/
