0

Scenario: using git to push to a remote repo. Local and remote are regular git repos, not encrypted. Putting a possible ecryptfs filesystem within a folder within the repo to be pushed.

If: a git pre-hook would assure unmounting the folder(umount ~/encrypted_folder/), and echo to command line something like " the folder containing an encrypted ecrypfs file system was closed", then git would push the repo to it's remote location including the folder that contains the encrypted filesystem after having assured the folder was unmounted, so the encryption stands. To "umount" no password is asked for. No technical complications to regular git functionality to be observed.

What would be the undesirable consequences?

One is evident: version controlling an encrypted file or folder would be irrelevant. That is acceptable.

Second: instead of git being frugal, would every push write the whole of the encrypted folder to the remote, and bloat the remote repository?

Third: would git "corrupt" in any way the encrypted folder?

Incentive: copying a folder containing an encrypted ecryptfs filesystem is trivial, tarring also, using rsync or scp is the evident suggestion, excluding that folder from being inside the repo, using ".gitignore" also ...

but for workflow reasons: git being used for backup, disregarding the versioning of the folder that contains encrypted filesystem, not having to recourse to anything else and keep things user trivial. One single git push to multiple remote locations for now takes care of all desired data backup per user. For workflow reasons, per user, it would be nice to keep it that way.

White paper: one single backup blob, mostly versioned, and being able to have some encrypted data within the repo and it's remote clones. Prohibiting the folder concerned from being "open" by the git pre-hook. Everything in one single git operation. Ecryptfs contains within the encrypted part of the data, anything needed to "open and close" the data but the passphrase. This would make for high mobility, needing to clone the remote repo to any git-ecryptfs enabled device, in any remote location and have access to the encrypted data.

m___
  • 101
  • 1
  • `git push` doesn't deal in files: it pushes *objects*. The Git that is receiving those objects stores them in its database (if the push is successful) and updates some reference names, and in general this succeeds only when the receiving Git is a `--bare` clone (has no work-tree, so there is nothing checked out) or does not have the pushed-to branch checked out (so there is nothing to check out). If you, as a person in control of the receiving Git, write a hook to do something with incoming objects, anything encryption-related is up to *you*. – torek Jan 11 '18 at 15:58
  • let me clarify my question: what git push does in with normal files and directories we agree, what git at the receiving end does also: only the changes are written what keeps git frugal, and in transit, and in storage. The question relates as to when an encrypted file is pushed, will it be written from start to end, since git does not "see" the incremental changes in the encrypted files, thus bloating the repo at the receiving end? – m___ Jan 11 '18 at 22:20
  • At least one of us is still confused. :-) Note that Git doesn't store directories, it just stores commits that store files (blobs, really) that have path names. It also doesn't store *changes*: each file (blob) is, logically at least, stored as a complete snapshot. (Internally, blobs are compressed against each other using a variant of xdelta compression, plus deflate compression, inside what Git calls a *pack*. If the blob contents are encrypted, and the encryption is any good, the blob-vs-blob compression will be poor.) – torek Jan 12 '18 at 00:33
  • Indeed, my summary idea of how keeping track of changes was technically wrong. – m___ Jan 13 '18 at 21:11
  • Can you confirm that the blob of an encrypted file as to the unencrypted file after several commits would be comparable in size and not "bloat" the repo after several commits. – m___ Jan 13 '18 at 21:26
  • Would the sum of snapshots of an encrypted file after several commits still be comparable to a file of the same size that is not encrypted at it's origin? I suspect so, and your comment adds to my suspicion, as does git-crypt a binary that allows encrypted files in a regular repo, that there is no problem versioning encrypted files with git. – m___ Jan 13 '18 at 21:28
  • Or the compression on encrypted data being poor, would an encrypted file upon each commit bloat the blob disproportionally as to what the blob-size of a regular file would be. – m___ Jan 13 '18 at 21:33
  • The details will depend on your encryption, but see https://crypto.stackexchange.com/questions/37367/can-shannons-entropy-be-used-to-determine-if-a-file-is-encrypted and note that compression in general depends on low input entropy. So in general xdelta will fail to compress a blob with hash H against any other blob with other hash if all such blobs are encrypted. – torek Jan 13 '18 at 21:37

0 Answers0