reopen

2 files changed, 35 insertions, 3 deletions

diff --git a/doc/bugs/feature_request:_pubkey-only_encryption_mode.mdwn b/doc/bugs/feature_request:_pubkey-only_encryption_mode.mdwn
index ff2fe7fae..2bfc629dd 100644
--- a/doc/bugs/feature_request:_pubkey-only_encryption_mode.mdwn
+++ b/doc/bugs/feature_request:_pubkey-only_encryption_mode.mdwn
@@ -1,6 +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.
+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?
 
-> [[closed|done]] per my comment --[[Joey]]
+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/bugs/feature_request:_pubkey-only_encryption_mode/comment_3_a37d5d27d073020ccf7eadb8e47d378a._comment b/doc/bugs/feature_request:_pubkey-only_encryption_mode/comment_3_a37d5d27d073020ccf7eadb8e47d378a._comment
new file mode 100644
index 000000000..1278aaab3
--- /dev/null
+++ b/doc/bugs/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/ 
+"""]]