Thanks for explaining. I guess the way to do a "cloud backup" would be
to do a "git archive" and then encrypt and scp the archive to the
On Wed, Jan 9, 2013 at 2:30 PM, Dale R. Worley <wor...@alum.mit.edu> wrote:
>> From: John McKown <john.archie.mck...@gmail.com>
>> This may be a rather ignorant question. It is based on the thread: "Can Git
>> do all of this?". Konstantin indicated that Web suppliers such as GitHub
>> are not secure. Why is this? Well, I guess maybe they could be hacked from
>> the outside, or perhaps an employee could be subverted. I am wondering why
>> there is not an git _option_ to mark a repository as "insecure". When
>> something is pushed to this "insecure" repository, the files being pushed
>> would be encrypted as they are being transferred (read data, encrypt, then
>> send). The reverse on a fetch or pull (receive, decrypt, write). This would
>> leave the files unencrypted on the user's machine.
> To implement this, you couldn't just encrypt the block of data sent to
> the remote repository, because then the remote repository couldn't
> organize proper shared data structures to represent all the commits.
> You'd have to encrypt the contents of each file individually. That
> would require the operations of sending/receiving from the repository
> to regenerate the directory-tree and commit objects based on the
> different file contents in the two repositories. That is a lot of
> code to put into a system which is not strongly worried about
> And if you want the remote Git to be able to see blocks of lines moved
> from one file to another, you have to arrange that any given line is
> encrypted the same way, regardless of where it appears in any file.
> That's possible, I think, with a degree of security, but makes the
> data cryptographically soft. (Hash the line concatenated to the
> secret key, use the hash to generate a keystream, XOR the keystream
> with the contents of the line, ciphertext is the hash concatenated
> with the XORed line contents.)
> If you want to implement it simply, I'd suggest having a program that
> synchronizes an unencrypted working copy directory with an encrypted
> Git working copy directory: make a change in the code, sync to the
> encrypted file tree, Git check in, push to remote repository.
> Otherwise, you have to change the plumbing deep down in Git.