diff options
author | guilhem <guilhem@web> | 2013-08-22 18:42:28 +0000 |
---|---|---|
committer | admin <admin@branchable.com> | 2013-08-22 18:42:28 +0000 |
commit | 366b7695d6d81af670c441c848754c0925b2d995 (patch) | |
tree | a1b2ab4a23d40afca3bbcd5bea5ab34e0375c1b7 | |
parent | ed924fe82a341de4b27213448f405240b8c9ca06 (diff) |
Added a comment
-rw-r--r-- | doc/bugs/Using_a_revoked_GPG_key/comment_9_f50c802d78041fd1522f0e7599ce6a45._comment | 42 |
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... + +"""]] |