Matthew England wrote:
> At 10/29/2004 03:27 AM, Max Bowsher wrote:
>> Matthew England wrote:
>>> As per: http://svnforum.org/forum/viewtopic.php?t=120 ...
>>>
>>> I would like to have Subversion auto-encrypt any file
>>> submissions/updates
>>> to it's repository (with something like a PGP public key), thus
>>> requiring
>>> anyone who gets/reads said file to have some sort of private decryption
>>> mechanism
>>
>> What you propose above would require source code changes (probably quite
>> major) to subversion, and doesn't actually obtain any extra security at
>> all, except in the single circumstance of the server's hard disc being
>> stolen.
>
> ...and in cases where someone cracks the SSL (unlikely) or simply acquires
> the access login/password, assuming I'm understanding things
> correctly. (Essentially: I see a different between having access to data
> being able to decrypt data.) I could probably dream up other scenarios.
>
> I would hope private keys can be distributed physically and are much
> harder
> to "steal" because they are contained in an encoded file...and one could
> theoretically make a different private key for each access (SSL) login
> (possibly).
In that case, the encryption would have to happen on retrieval *from* the
repository, not on addition *to* the repository.
Perhaps SSL client certificates would suit your purposes? IIUC, they would
perform more-or-less what you are trying to achieve, without you having to
write code yourself.
> In any case, this approach apparently is neither easy nor generally
> practiced in the config-management/subversion community...which is mostly
> what I wanted to know, and I now I know, or at least have some sort of
> initial "temperature" reading on this stuff.
Subversion generally delegates complicated authn/authz to Apache, because it
is a large flexible pre-existing base of code in this area.
Would an encrypting filesystem combined with SSL client certs provide
something near enough to your goal? Because that is a solution that could be
assembled from "off-the-shelf" components, using unmodified Subversion code.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 29 15:06:29 2004