1 files changed, 0 insertions, 42 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
deleted file mode 100644
index d86de4e1b..000000000
--- a/doc/bugs/Using_a_revoked_GPG_key/comment_9_f50c802d78041fd1522f0e7599ce6a45._comment
+++ /dev/null
@@ -1,42 +0,0 @@
-[[!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...
-
-"""]]