From eddb9daa69d381a0315f81e3c917c448770129a1 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 27 May 2015 15:09:56 -0400 Subject: [PATCH] followup --- ..._06611859079239659ba7d73d655f517e._comment | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 doc/special_remotes/ipfs/comment_4_06611859079239659ba7d73d655f517e._comment diff --git a/doc/special_remotes/ipfs/comment_4_06611859079239659ba7d73d655f517e._comment b/doc/special_remotes/ipfs/comment_4_06611859079239659ba7d73d655f517e._comment new file mode 100644 index 0000000000..6955bfe163 --- /dev/null +++ b/doc/special_remotes/ipfs/comment_4_06611859079239659ba7d73d655f517e._comment @@ -0,0 +1,23 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2015-05-27T19:02:30Z" + content=""" +@rob.syme, the reason that does not work when using encryption +is that git-annex internally generates an encrypted key, and stores +that on IPFS. The ipfs special remote records the IPFS address +that can be used for a key, but it's recorded on the encrypted +key, which is not the one you're querying with whereis. + +This is a general problem with git-annex; ipfs is probably the +first special remote that exposes the problem. + +Anyway, I'm not sure what benefit knowing the IPFS address of a file +encrypted by git-annex is. You need to use git-annex to decrypt it, in +general. You might be able to use your gpg key to decrypt it, if the +special remote was set up using pubkey encryption, but that's not going to +help anyone else you give the IPFS address to access the encrypted data.. + +Does your use case involve pinning the IPFS address, or something like +that? +"""]]