Enrico Weigelt [off-list ref] writes:
quoted
Enrico Weigelt [off-list ref] writes:
quoted
* 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.
quoted
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.
quoted
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.
quoted
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.weigelt@vnc.biz; www.vnc.de
On Fri, Sep 7, 2012 at 8:34 PM, Enrico Weigelt [off-list ref] wrote:
quoted
quoted
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.
quoted
quoted
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