[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Encrypted Repositories. . .?

From: Michael Williams <gberz3_at_gmail.com>
Date: 2007-06-20 22:05:45 CEST

On Jun 20, 2007, at 1:58 PM, Dan Shookowsky wrote:

> I think the point that many folks have been trying to make with
> regards to this situation is that it makes no sense to put a
> padlock on a paper bag. You could have SnakeOil(tm) Brand 4096-bit
> elliptic curve encryption of your source, but if you can't restrict
> the users who have access to the machine, there's no preventing
> someone from using those same libraries to decrypt it using the
> same keys.
> The other issue that someone mentioned is that you lose the
> functionality provided by svn because your source simply becomes an
> opaque binary object that can't be merged, blamed, etc. In that
> scenario, you might as well have the repository on a (trusted)
> local developer machine and ftp up encrypted dumps of the
> repository to a central server or something equally ridiculous

I'm not concerned about the lost functionality or source. It's more
a "if I can't have the source nobody can". The source can be merged
and blamed, because, for at least a short period, it is decrypted to
perform those functions; after which the repository is re-
encrypted. Again, my desire is for SVN to encrypt it's very
processes with a random key so that while these processes are
occurring it can't be hacked. Obviously anything could be hacked,
but as I said, it's just an extra level.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 20 22:06:20 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.