subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruchir Arya <ruchira...@gmail.com>
Subject Re: Changeset Signing
Date Mon, 03 Aug 2015 19:56:16 GMT
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 
>
>
Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message