Martin Eisenhardt wrote:
[snip]
>> but can files stored in a repository be encrypted?
>> The server, that is to host subversion, is maintained by students working for our chair.
>> They must not be able to read the contents of the repositories.
>
> Try solving these issues with traditional Linux/Unix/Windows tools, file
> system access privileges, or similar.
That will not do the trick, as others posted below.
>>Is there a way to automatically encrypt the files before storing them in
>>a repository. It would be okay if all repositories would be encrypted in
>>the same way.
If you carefully define "before storing" then yes, there can be a way out.
If only we had client-side hooks... but we don't, at least for the foreseeable future.
So you need a wrapper. A wrapper that encrypts the files on-the-fly, before they leave _your_
machine. They will be stored on the server encrypted. They will be checkout-ed (I know this is wrong
English) or exported encrypted, so you need to decrypt them on-the-fly. In your working directory
they will be decrypted (i.e. plain text, or whatever original format), so any _local_ diffs will
work just as before.
Cool! I actually like this idea very much!
You can use PGP (like from gnupg) or other (X.509) form of strong encryption.
And if you dig deep enough in the source of the library, this all can be transparent, absolutely
transparent to implement!
> That way, subversion would not be able to derive diffs between files, so the
> repository would soon grow HUGE
Yes, unfortunately. If the diffs are small, your encryption algorithm is weak.
> and larger parts of subversion's functionality would seize to work.
Not sure what is meant here. More details?
> It would be very similar to the case where you only have binary files in a repository:
> no diffs, no incremental updates, ...
You can have diffs in binary files if your client can handle them. A very easy, more like
proof-of-concept, example is a compressed (gzip-ed) xml file: Use vimdiff and you have it
uncompressed on-the-fly (WARNING: not tested!).
If only I had more time to implement all great ideas...
Bear in mind, that this is more like a trick in your situation. Even the strongest encryption can be
broken in a certain amount of time. And in this scheme changing the keys is not a big option. Plus
the inherited weakening (by providing diffs of the same plain text) might be a factor.
Kalin.
--
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 26 17:46:52 2005