Fwd: Encrypted Repositories?
kerinin at gmail.com
Thu Sep 6 19:43:57 CDT 2007
> For disk encryption, there are several existing mechanisms. Loop-back
> cryptfs in linux, bitlocker or equivalent in Windows.
Maybe, maybe not. I haven't taken the time to encrypt my linux box
despite knowing how to because it's a hassle (my mac is encrypted
because there's a checkbox for it). it seems like the biggest
weakness with encryption is making it accessible enough for people to
use it. Aside from the difficulty of setting up the filesystem,
you're still locked into an all-or-nothing situation. I might want to
be able to walk away from my computer for a few hours without logging
out but not leave my repository open to anyone wandering past my desk.
> None of this will help you on a hacked server unless the files are
> *always* encrypted on the server (that is: decryption key not present on
> server at all).
that was the idea. The keys could be on the server if they had a
password (although this clearly isn't ideal).
> I don't know if this will actually work, but it seems to me that it is
> worth a try: run gpg on the client side as an import/export filter. I
> would be very curious to learn whether this works. The missing link
> there is going to be that the commit log entry and other metadata will
> not get encrypted. How much of what you want will this buy you? If you
> run gpg-keyserver, you won't even need to type pass-phrases.
You're right - the metadata a problem. I wasn't sure how it was
stored. Doesn't make much sense to encrypt the code if all your
comments about how it was developed is in the clear...
> Lots of waste here. To do this right you want a group key management
> scheme, because you will eventually want to be able to revoke the key of
> some user.
More information about the Mercurial-devel