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