You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ruchir Arya <ru...@gmail.com> on 2015/08/03 21:56:16 UTC
Re: Changeset Signing
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
>
>
Re: Changeset Signing
Posted by Mark Phippard <ma...@gmail.com>.
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 <ru...@gmail.com> 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/