On Wed, Jan 24, 2018 at 09:50:27AM +1100, Timothy Rice wrote: >> It's probably easier to let the encryption be at file system level and let >> the hard drive handle it - maybe. > > The problem with this is that it doesn't require collaborators to also use > encryption. It also assumes that at least one of fuse and dm-crypt are > enabled in the kernel (assuming Linux). [...] > So, although I don't want to discount the technical challenges that could > be involved in providing an encryption layer for Git, I personally would be > quite interested in whether it might be possible. [...]
I think that encryption can be implemented with stock Git with a wrapper. (And I have heard of at least one commercial implementation of this approach — IronGit™ [1]; note that I'm not affilicated with that product/company in any way.) One possible approach would be using the so-called clean/smudge filters which could be set up for all types of files in a way that smudge filters decrypt and clean filters encrypt. But considering the whole picture hints at more general problems. I'd list these: - Ideally different developers must have their own private keys so that they can be revoken when needed w/o affecting the rest of the team. The repository should not require total reencryption when this happens. Something akin to [2]. I'm not that versed in cryptography to tell whether it's possible with the contemporary algorithms. The same applies to digital signing (encryption w/o signing is not too interesting anyway). - The PKI part should be supported to a certain extent. - The set of algorithms used should somehow be future-proof (that is, be eligible for gradual upgrading, when needed). Having said that, I don't *clearly* see the point of encrypting Git repositories: - Shared (rendez-vouz) repositories can be hosted on properly contained premises and be allowed access only via trusted means (SSH with personal keys and/or HTTPS with personal certs being validated on the server side). - A local clone a developer makes will still have the work tree in order to be useful. That is, such a repo would consist of an encrypted object store and one plain text snapshot of that in the work tree. In order to secure this, you'd have to use filesystem-level or block device-level encryption, but once you start using it the necessity of encrypting the repository's object store becomes questionable. 1. https://atcipher.com/irongit/ 2. https://www.schneier.com/blog/archives/2012/08/shared_lock.html -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
