Google Summer of Code: Encrypted branch/repository format status

[Bogdano Arendartchuk]

On Tue, Jul 17, 2007 at 10:34:37AM -0500, John Arbash Meinel wrote:
> Martin Pool wrote:
[snip]
> > 
> > The other question in my mind is whether this really needs to come in
> > at the knit level.  Could you instead interpose an encrypting
> > transport for access to some files?  I realize random access may be a
> > bit hard to get just right, but that's probably no worse than for
> > doing it in a knit... The transport interface is pretty stable.

Working in the transport level would allow much more flexible security
schemes, as it can be more generic. But I think it's harder than just
changing specific pieces of knit, branch and bzrdir, even relying in code
without stability guarantee.

> 
> Transport would probably be interesting. I'm not sure how it would
> encrypt the filenames in the same way, but it at least seems possible.
> You could have a custom BzrDir that at .open() time would re-wrap its
> Transport in an EncryptedTransportWrapper, which would munge filenames
> and file contents as appropriate.
> 
> I really think that anything of this sort of security should have a bit
> of discussion about what sort of attacks are possible, and what it is
> trying to defend against.
> 
> Specifically, some things that I don't think he is trying to hide:
> 
> a) That there is a Bazaar Branch of some sort at that location. (This
> would effect discovery, and some other things). Specifically, you would
> probably want to obfuscate the '.bzr' directory if you were trying to
> avoid this. Since we aren't, it means that .bzr/ and the general
> meta-information files can stay put (you don't have to hide where
> .bzr/repository/inventory.knit is, you just want to hide the *contents*
> of the file).
> 
> b) When information is added to the repository. It would be possible to
> pre-allocate a certain amount of data and fill it with randomness, and
> always modify some of the randomness to hide just what is being updated
> and when. I'm pretty sure we aren't trying for this level of security.
> If someone really wants more, they should look into something like
> TrueCrypt and mount an encrypted filesystem, and then publish their
> encrypted volume.
> 
> c) We aren't trying to prevent a hacker who has local root access from
> reading the contents from in-memory. Not to mention that once you have
> done a checkout, you have the real contents on-disk.
> 
> d) We aren't trying to prevent someone who *has* access from
> accidentally checking out a working copy in the public location (maybe
> we are).
> 
> e) I think we are looking mostly for a "I want to host my project on a
> 'public' location, but don't want everyone to have access to it". In
> this case, I'm not sure if we need to hide file-ids, though we might,
> since in the current bzr code, it reveals some information about filenames.

I was going to reply for c) and d), but that's close to what was in my GSoC
proposal.

> 
> I believe the current codebase is decent about having a transport
> pointed at '.bzr/repository' and another one pointed at
> '.bzr/repository/knits/', and then all access for all Knits goes through
> the 'weave_transport' (which is the one pointing at Knits).
> 
> So it would be possible to override '_get_versioned_file_store()' and
> set the 'munge_filenames=True' flag for that transport, while the other
> transports would only have the 'encrypt_file_contents=True'.
> 
> You *wouldn't* want to encrypt the .bzr/branch-format file, and probably
> want to leave the README, etc alone. But most likely all other files
> could have there contents encrypted.
> 

Thanks for the pointers! I will have a deeper look in Transport and what I
can do. I'll ask more later.

-- 
Bogdano Arendartchuk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070717/bb737444/attachment.pgp