move to todo

4 files changed, 85 insertions, 0 deletions

diff --git a/doc/todo/feature_request:_pubkey-only_encryption_mode.mdwn b/doc/todo/feature_request:_pubkey-only_encryption_mode.mdwn
new file mode 100644
index 000000000..2bfc629dd
--- /dev/null
+++ b/doc/todo/feature_request:_pubkey-only_encryption_mode.mdwn
@@ -0,0 +1,14 @@
+### Feature request
+
+It is not possible to put encrypted content in place on remotes with just a
+public GPG key. You always need the private key, even for encryption. I
+guess this is because how the cipher HMAC is used for replacing file names
+with their hashes. However, if that requirement (having secret file names)
+was dropped, I assume a pubkey-only mode could be implemented?
+
+My specific use case is backup archiving. I have my backups packed in
+archive files and want to use git-annex to copy the archives to offsite
+remotes (S3). In that case, I don't care much about hiding file names, but
+would appreciate the increased security of not having the secret key on the
+backup server. It would only be needed if I wanted to verify or restore
+backups.
diff --git a/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_1_684d36c06429306be68fd60019564db3._comment b/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_1_684d36c06429306be68fd60019564db3._comment
new file mode 100644
index 000000000..0e2f5e3ba
--- /dev/null
+++ b/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_1_684d36c06429306be68fd60019564db3._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-03-31T19:37:20Z"
+ content="""
+When you use encryption=pubkey, the symmetric key that is used for
+HMAC encryption of filenames is encrypted using your gpg private key.
+The contents of files are also encrypted using your gpg private key
+(not using the symmetric key; that mode is encryption=hybrid).
+
+So, with encryption=pubkey, all that can be done with that symmetric key is
+to HMAC encrypt filenames and try to find results that match the HMACed
+filenames used on the remote. So, if you don't care about filenames
+leaking, you could publish that symmetric key with no bad effects. Its
+security is not important to you based on what you've said.
+
+But again, that symmetric key is encrypted with your gpg private key.
+The only way to decrypt it would be to break your gpg key somehow. In which
+case you have big problems. But not ones caused by the existence of the
+symmetric key.
+
+So, I see no benefit to the suggested mode.
+"""]]
diff --git a/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_2_13995d4f1142a393ff977859b86497b4._comment b/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_2_13995d4f1142a393ff977859b86497b4._comment
new file mode 100644
index 000000000..88a45312d
--- /dev/null
+++ b/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_2_13995d4f1142a393ff977859b86497b4._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl6rte43qSRK1o2zn7Ww4Z8pgBmJm8gDrc"
+ nickname="Rickard"
+ subject="comment 2"
+ date="2015-04-04T07:34:58Z"
+ content="""
+> The contents of files are also encrypted using your gpg private key
+
+I assume you meant to say gpg *public* key here?
+
+You're correct in that I can publish the symmetric HMAC key unencrypted with no bad effects for me. I've searched the documents but haven't found a way to tell git-annex to use a specific, unencrypted, symmetric key for HMAC, though. Is there a way?
+
+> So, I see no benefit to the suggested mode.
+
+I don't understand the reasoning that made you come to this conclusion.
+
+Let me restate my use case:
+
+With only the public part of a gpg key id available to a user, I would like that user to be able to add files to a git-annex repository. The user should then be able to copy the files encrypted to remotes that support encryption (S3 etc). The user should not be able to fetch or verify files from the encrypted remotes (since she lacks the private gpg key). The remote would be write-only for the user, basically. However, a friend of the user, posessing the private key (and having access to the remote), should be able to use the remote just like a normal git-annex remote.
+
+This is the normal way of using gpg for asymmetric encryption of files. I would find it useful to be able to use git-annex in a similar way. As far as I can understand, only the encrypted HMAC key is stopping me from using git-annex in this way. 
+
+However, there might be other things in git-annex' design that would make it difficult or even impossible to implement this functionality. It could also be the case that there's no benefit to adding this functionality to git-annex because there is some other (simpler) way to achieve the same thing. Both these cases are perfectly acceptable, but I would then be interested in knowing a bit more details.
+"""]]
diff --git a/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_3_a37d5d27d073020ccf7eadb8e47d378a._comment b/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_3_a37d5d27d073020ccf7eadb8e47d378a._comment
new file mode 100644
index 000000000..1278aaab3
--- /dev/null
+++ b/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_3_a37d5d27d073020ccf7eadb8e47d378a._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-04-06T17:04:34Z"
+ content="""
+I somehow completely misread what you wanted! Thanks, it makes sense now.
+
+I anticipate there would be one problem with this mode; `git annex fsck --from remote` 
+would fail because it would be unable to decrypt the encrypted content
+when run on the client that is only able to encrypt to the public key, but
+lacks the necessary private key to decrypt.
+
+(So would `git annex move --to remote; git annex get --from remote`, but
+presumably that failure is the point of the mode..)
+
+It would be fairly easy to add this, I think. There is already support
+for configuring the MAC algorithm to use to encrypt filenames. Your mode seems
+to just need a "clear" mode that doesn't encrypt filenames at all.
+
+It does add complication to crypto paths, and potential for user
+foot-shooting though.
+
+I'm going to move this feature request from bugs/ to todo/ 
+"""]]