What about a GPGesque setup?
1) Create keys for client and server.
2) Have the client encrypt the files to the server keys
3) Have the server decrypt and compare
4) Have the server encrypt to the client keys
. . .of course this would likely only work for commits, but we could
either reverse the process (basically a dual-server setup. . .boo) or
engineer some other mechanism. It's late, I'll think on this tomorrow.
Thanks for all input thusfar. . .
On Jun 20, 2007, at 2:23 AM, Matt Sickler wrote:
> No, SVN does not have this functionality itself.
> Modifying the filesystem bit of the RepositoryAccess layer to allow
> encryption might be an option for your company if they want to invent
> the time/money.
> Not sure how well that would work with the way SVN works, as the
> server computes the diffs itself, thus it would need access to the
> plaintext (and thus the keys), so its really not possible I believe.
>
> On 6/20/07, Michael Williams <gberz3@gmail.com> wrote:
>> Please see my last post. I understand what you're saying, but it
>> doesn't matter whether they're root or not if the actual repository
>> itself is encrypted with keys. I realize that I will lose a bit of
>> the other SVN convenience (e.g. plain text files), but I'm not
>> concerned about that. I realize too that this would increase server
>> load; again, not my concern. My only goal is source control that is
>> encrypted both in transmission and persistence.
>>
>> Understand too, my concern with potential physical theft. Granted,
>> that's not very likely, but it's not impossible either. In the event
>> that drives and/or data come up missing (e.g. Anthem BCBS, TJ Maxx,
>> Marshall's), I'd rather know that no one is getting my source.
>>
>> As far as encrypting first, I don't think this is a good solution, as
>> I want to maintain integrity with the source control so this needs to
>> happen on the server side. I see the process as occurring something
>> like this:
>>
>>
>> Client < -- > SSL Traffic < -- > Unencrypted Comparison < -- >
>> Encrypted Repository
>>
>> . . .If I understood the guts of the SVN system better, I wouldn't
>> mind getting my hands dirty and just writing it myself; but I'm
>> hoping something like this already exists somewhere.
>>
>>
>> On Jun 20, 2007, at 1:55 AM, Theo Van Dinter wrote:
>>
>> > On Wed, Jun 20, 2007 at 01:10:32AM -0400, Michael Williams wrote:
>> >> That's just it. They have access to the folders in which our
>> source
>> >> is saved, so if we could have some sort of PKI to encrypt the
>> >> repository on the disk it wouldn't matter who had access (root or
>> >> otherwise) as long as they don't have our keys.
>> >
>> > The point was that if others have root, you really have no
>> > protection of
>> > your data. They can modify your binaries, your config, read the
>> > process'
>> > memory, etc.
>> >
>> > I suppose you could modify the svn clients such that they encrypt
>> > the data before sending it to the server, such that the subversion
>> > repository would be full of encrypted files. Then your data is
>> never
>> > available in plaintext on the server.
>> >
>> > My POV is that it would be easier/more efficient to just get a
>> server
>> > that you can trust, but YMMV. :)
>> >
>> > --
>> > Randomly Selected Tagline:
>> > "I gotta be sure this isn't another scientific fraud like global
>> > warming
>> > or second-hand smoke." -Mayor
>>
>> ---------------------------------------------------------------------
>> 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 08:31:41 2007