Re: Encrypted repositories
Well, everybody can access the objects, but they're encrypted, so you need the repo key (which, of course isn't contained in the repo itself ;-p) to decrypt them. So, in short, blobs are not encrypted with the hash of their contents as encryption keys at all. No, the blobs are encrypted with their content hash as key, and the encrypted blob will be stored with it's content hash as object id. For the usecases I have in mind (backups, filesharing, etc) this wouldn't hurt so much, if the objects are compressed before encryption. For that kind of usage pattern, you are better off looking at encrypted tarballs or zip archives. No, that doesn't give us anything like history, incremental synchronization, etc, etc. What I finnaly wanna has is a usual git, just with encryption, but I can live with loosing differential compression. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Encrypted repositories
On Fri, Sep 7, 2012 at 8:34 PM, Enrico Weigelt enrico.weig...@vnc.biz wrote: Well, everybody can access the objects, but they're encrypted, so you need the repo key (which, of course isn't contained in the repo itself ;-p) to decrypt them. So, in short, blobs are not encrypted with the hash of their contents as encryption keys at all. No, the blobs are encrypted with their content hash as key, and the encrypted blob will be stored with it's content hash as object id. For the usecases I have in mind (backups, filesharing, etc) this wouldn't hurt so much, if the objects are compressed before encryption. For that kind of usage pattern, you are better off looking at encrypted tarballs or zip archives. No, that doesn't give us anything like history, incremental synchronization, etc, etc. What I finnaly wanna has is a usual git, just with encryption, but I can live with loosing differential compression. Something like this? https://gist.github.com/873637 I've never tried it myself, who knows if it works, but google found it when I searched for git clean smudge filter encryption. I hope that helps, -- David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Encrypted repositories
Hi, Enrico Weigelt enrico.weig...@vnc.biz writes: * blobs are encrypted with their (original) content hash as encryption keys What does this even mean? Is it expected that anybody who has access to the repository can learn names of objects (e.g. by running ls .git/objects/??/)? If so, from whom are you protecting your repository? Well, everybody can access the objects, but they're encrypted, so you need the repo key (which, of course isn't contained in the repo itself ;-p) to decrypt them. The whole tree will still be consistent even without encryption support (so, gc etc shouldn't break), but to actually _use_ the repo (eg. checkout or adding new commits), you'll need the encryption support and the repo key (well, committing should theoretically even work with diffrent repo key, even this doesn't make much sense ;-)). How does this encryption interact with delta compression employed in pack generation? Probably not at all ;-o For the usecases I have in mind (backups, filesharing, etc) this wouldn't hurt so much, if the objects are compressed before encryption. cu -- Mit freundlichen Grüßen / Kind regards Enrico Weigelt VNC - Virtual Network Consult GmbH Head Of Development Pariser Platz 4a, D-10117 Berlin Tel.: +49 (30) 3464615-20 Fax: +49 (30) 3464615-59 enrico.weig...@vnc.biz; www.vnc.de -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Encrypted repositories
Enrico Weigelt enrico.weig...@vnc.biz writes: Enrico Weigelt enrico.weig...@vnc.biz writes: * blobs are encrypted with their (original) content hash as encryption keys What does this even mean? Is it expected that anybody who has access to the repository can learn names of objects (e.g. by running ls .git/objects/??/)? If so, from whom are you protecting your repository? Well, everybody can access the objects, but they're encrypted, so you need the repo key (which, of course isn't contained in the repo itself ;-p) to decrypt them. So, in short, blobs are not encrypted with the hash of their contents as encryption keys at all. How does this encryption interact with delta compression employed in pack generation? Probably not at all ;-o For the usecases I have in mind (backups, filesharing, etc) this wouldn't hurt so much, if the objects are compressed before encryption. For that kind of usage pattern, you are better off looking at encrypted tarballs or zip archives. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Encrypted repositories
Enrico Weigelt enrico.weig...@vnc.biz writes: * blobs are encrypted with their (original) content hash as encryption keys What does this even mean? Is it expected that anybody who has access to the repository can learn names of objects (e.g. by running ls .git/objects/??/)? If so, from whom are you protecting your repository? How does this encryption interact with delta compression employed in pack generation? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
