summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar guilhem <guilhem@web>2013-08-22 18:42:28 +0000
committerGravatar admin <admin@branchable.com>2013-08-22 18:42:28 +0000
commit366b7695d6d81af670c441c848754c0925b2d995 (patch)
treea1b2ab4a23d40afca3bbcd5bea5ab34e0375c1b7
parented924fe82a341de4b27213448f405240b8c9ca06 (diff)
Added a comment
-rw-r--r--doc/bugs/Using_a_revoked_GPG_key/comment_9_f50c802d78041fd1522f0e7599ce6a45._comment42
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...
+
+"""]]