Added a comment

1 files changed, 42 insertions, 0 deletions

diff --git a/doc/bugs/Using_a_revoked_GPG_key/comment_9_f50c802d78041fd1522f0e7599ce6a45._comment b/doc/bugs/Using_a_revoked_GPG_key/comment_9_f50c802d78041fd1522f0e7599ce6a45._comment
new file mode 100644
index 000000000..d86de4e1b
--- /dev/null
+++ b/doc/bugs/Using_a_revoked_GPG_key/comment_9_f50c802d78041fd1522f0e7599ce6a45._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="guilhem"
+ ip="129.16.20.209"
+ subject="comment 9"
+ date="2013-08-22T18:42:28Z"
+ content="""
+Hehe, I ran into the option parser issue when implementing that change
+;-) So I moved to `git annex enableremote ... [keyid+=newkey]
+[keyid-=oldkey]` (where `+` is optional, for consistency) which doesn't
+prevent users from specifying a key by something starting with a sign.
+
+While it's certainly possible to tell git-annex to manage the authorized
+keys itself, users may have other reasons to remove a key so I'm not 
+sure it's a good idea. Also, what if someone forgets to add his/her new 
+key after revocation (it's still possible to decrypt after all)? If 
+another person updates the keyring afterwards, the first user will be
+denied further access, and will have to retrieve and reencrypt the
+\"cipher\" manually, which is not so trivial.
+
+
+I understand that asymmetric encryption needs special care, but Sam's 
+use case could be reproduced with that scheme I believe. For instance a
+user may superseed and revoke his/her old key; then new files would be 
+uploaded with the new one, but as long as the old key is not 
+compromised, I don't see why s/he should reupload everything instead of
+using the old key when pulling from the remote. Of course one may argue
+that the key shouldn't be revoked at the first place, but if it's used
+for other purposes (e.g., it's publicly available on a key server) it's
+good practice to revoke it IMHO.
+
+As for the removal of keys with pure asymmetric encryption, it is just
+required I think: Otherwise revoking a key would prevent any further 
+content to be encrypted. There I can't see any problem with git-annex 
+managing the keyring itself (beside the extra code to write :-P).
+
+All in all if we are to allow deletion/addition of keyIDs (and I think 
+we should!), I think it should be done for both `hybrid` and `pubkey` 
+schemes. Do you really want another syntax? I'd say clarify the manage 
+(plus maybe a warning when running the CLI) is enough, but true it's 
+easy to shoot oneself in the foot there...
+
+"""]]