Perhaps it *could* *somehow* *maybe* be hacked together to "work".
SVN does not supply encryption of anything (except the link between
server and client when you use https or ssh+svn). If you want to
encrypt the repository, use an encrypted filesystem with a on-boot (or
on-mount) passphrase.
Anything else is just going to be a headache, cost a ton of money,
and probably remove what little sanity you seem to have left.
On 6/20/07, Michael Williams <gberz3@gmail.com> wrote:
> On Jun 20, 2007, at 10:50 AM, Greg Thomas wrote:
> >
> > Well, I can see a way it could be. svn is enhanced such that the code
> > is encrypted at the client side, and then passed over the network and
> > stored on disk, still encrypted. When you check out the code, it's
> > decrypted client side.
> >
> > The drawback is that all files would essentially become binary and
> > hence non-mergable.
> >
> > Greg
>
>
> Well, I don't have a problem with the temporary "vulnerability" of
> the encrypt/decrypt process. After all, that would be no less secure
> than the current status. My concern would be with physical theft of
> the machine or "hackers" acquiring something on the level of FTP
> access and snatching the files. In either of these two cases I'd
> prefer to know that my resultant data is encrypted in place. Does
> that make sense?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 20 17:27:19 2007