From: Ævar Arnfjörð Bjarmason <firstname.lastname@example.org> To: Jonathan Nieder <email@example.com> Cc: Alex Vandiver <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Michael Haggerty <email@example.com> Subject: Re: Per-object encryption (Re: Git Merge contributor summit notes) Date: Mon, 26 Mar 2018 23:22:18 +0200 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20180326205349.GA21735@aiede.svl.corp.google.com> On Mon, Mar 26 2018, Jonathan Nieder wrote: > Hi Ævar, > > Ævar Arnfjörð Bjarmason wrote: > >> It occurred to me recently that once we have such a layer it could be >> (ab)used with some relatively minor changes to do any arbitrary >> local-to-remote object content translation, unless I've missed something >> (but I just re-read hash-function-transition.txt now...). >> >> E.g. having a SHA-1 (or NewHash) local repo, but interfacing with a >> remote server so that you upload a GPG encrypted version of all your >> blobs, and have your trees reference those blobs. > > Interesting! > > To be clear, this would only work with deterministic encryption. > Normal GPG encryption would not have the round-tripping properties > required by the design. Right, sorry. I was being lazy. For simplicity let's say rot13 or some other deterministic algorithm. > If I understand correctly, it also requires both sides of the > connection to have access to the encryption key. Otherwise they > cannot perform ordinary operations like revision walks. So I'm not > seeing a huge advantage over ordinary transport-layer encryption. > > That said, it's an interesting idea --- thanks for that. I'm changing > the subject line since otherwise there's no way I'll find this again. :) In this specific implementation I have in mind only one side would have the key, we'd encrypt just up to the point where the repository would still pass fsck. But of course once we had that facility we could do any arbitrary translation . I.e. consider the latest commit in git.git: commit 90bbd502d54fe920356fa9278055dc9c9bfe9a56 tree 5539308dc384fd11055be9d6a0cc1cce7d495150 parent 085f5f95a2723e8f9f4d037c01db5b786355ba49 parent d32eb83c1db7d0a8bb54fe743c6d1dd674d372c5 author Junio C Hamano <email@example.com> 1521754611 -0700 committer Junio C Hamano <firstname.lastname@example.org> 1521754611 -0700 Sync with Git 2.16.3 With rot13 "encryption" it would be: commit <different hash> tree <different hash> parent <different hash> parent <different hash> author Whavb P Unznab <email@example.com> 1521754611 -0700 committer Whavb P Unznab <firstname.lastname@example.org> 1521754611 -0700 Flap jvgu Tvg 2.16.3 And an ls-tree on that tree hash would instead of README.md give you: 100644 blob <different hash> ERNQZR.zq And inspecting that blob would give you: # Rot13'd "Hello, World!" Uryyb, Jbeyq! So obviously for the encryption use-case such a repo would leak a lot of info compared to just uploading the fast-export version of it periodically as one big encrypted blob to store somewhere, but the advantage would be: * It's better than existing "just munge the blobs" encryption solutions bolted on top of git, because at least you encrypt the commit message, author names & filenames. * Since it would be a valid repo even without the key, you could use git hosting solutions for it, similar to checking in encrypted blobs in existing git repos. * As noted, it could be a permanent stress test on the SHA-1<->NewHash codepath. I can't think of a reason for why once we have that we couldn't add the equivalent of clean/smudge filters. We need to unpack & repack & re-hash all the stuff we send over the wire anyway, so we can munge it as it goes in/out as long as the same input values always yield the same output values.
prev parent reply index Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-10 0:06 Git Merge contributor summit notes Alex Vandiver 2018-03-10 13:01 ` Ævar Arnfjörð Bjarmason 2018-03-11 0:02 ` Junio C Hamano 2018-03-12 23:40 ` Jeff King 2018-03-13 0:49 ` Brandon Williams 2018-03-12 23:33 ` Jeff King 2018-03-25 22:58 ` Ævar Arnfjörð Bjarmason 2018-03-26 17:33 ` Jeff Hostetler 2018-03-26 17:56 ` Stefan Beller 2018-03-26 18:54 ` Jeff Hostetler 2018-03-26 18:05 ` Brandon Williams 2018-04-07 20:37 ` Jakub Narebski 2018-03-26 21:00 ` Including object type and size in object id (Re: Git Merge contributor summit notes) Jonathan Nieder 2018-03-26 21:42 ` Jeff Hostetler 2018-03-26 22:40 ` Junio C Hamano 2018-03-26 20:54 ` Per-object encryption " Jonathan Nieder 2018-03-26 21:22 ` Ævar Arnfjörð Bjarmason [this message]
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
firstname.lastname@example.org list mirror (unofficial, one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox