On 9/19/05, svn-dev@cxxl.de <svn-dev@cxxl.de> wrote:
> hi,
>
> i hope this is the right place to ask for this:
>
> i'm looking for a solution to this problem: i use SVN for one year now
> and am very happy with it. until now, i use it only for myself. now,
> i'd like a second user to access the repo as well. since i don't
> operate my machine 24/7, we'd need to use some server. but we don't
> want to have to trust the server's operators not to copy the repo for
> whatever reasons for themselves.
Find someone you do trust: ultimately someone needs to have access to
machines and the data on it... (Or use Windows and user-encrypted
data: that shields the repository content from admins.)
Don't you think the question above is a server-management question,
which - not being a Subversion dev question - belongs on users@ ? The
list volume of this list is high enough as it is..
> could one add to SVN the ability to manage an encrypted repo and only
> decrypt it on the client side? in case anybody stole the repo or
> listened to the communications, he wouldn't get anything legible. the
> client(s) would know how to decrypt the data and how to interpret it.
No, the server needs access to the datastructures in the respository
in order to send the right responses to the client.
> somehow i think it should not be too hard to implement this.
On this list, we don't want to hear this: most features that are not
implemented, either are *very* hard, or we didn't have time to do
them.
> assuming
> you were using some cipher algorithm in ECB mode, you only needed to
> replace all calls of write(h, buf, cnt) with write(h, encrypt(buf),
> cnt) and vice versa with read() (i know, i'm simplifying, i just want
> to make a point).
Don't do that. Write a design proposal in which you address all
edge-cases and find out for yourself if it's easy. Please note that
there are a few limitations you have to work with:
- Your solution needs to be portable (ie work on windows and other
non-POSIX platforms)
- Your solution may not interfere with current client operations
- Your solution must be optional, so that those who don't want to
crypt() don't have to suffer the loss of efficiency
> what do you think of this?
Wanna try writing the proposal?
> ps: maybe this is some strange idea. if so, i'd like to know how
> other people solved similar problems. with so many people working
> from home, there must be someone with alike settings.
No, if you have security problems, people working at home may be your
problem, not the encryption of your repository...
bye,
Erik.
Received on Mon Sep 19 11:39:04 2005