From 810f4dfbe743617304daad415b5e5ce0485b777a Mon Sep 17 00:00:00 2001 From: guilhem Date: Mon, 19 Aug 2013 16:08:49 +0000 Subject: Added a comment --- .../comment_7_20dc5a7ce7cb6ca97ccdfb923c3b24bb._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/Using_a_revoked_GPG_key/comment_7_20dc5a7ce7cb6ca97ccdfb923c3b24bb._comment diff --git a/doc/bugs/Using_a_revoked_GPG_key/comment_7_20dc5a7ce7cb6ca97ccdfb923c3b24bb._comment b/doc/bugs/Using_a_revoked_GPG_key/comment_7_20dc5a7ce7cb6ca97ccdfb923c3b24bb._comment new file mode 100644 index 000000000..02be72e36 --- /dev/null +++ b/doc/bugs/Using_a_revoked_GPG_key/comment_7_20dc5a7ce7cb6ca97ccdfb923c3b24bb._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="guilhem" + ip="129.16.20.209" + subject="comment 7" + date="2013-08-19T16:08:49Z" + content=""" +On second thought, I think it makes more sense to have something like `git annex initremote ... encryption={none,shared,hybrid,pubkey} keyid=whatever` and `git annex enableremote ... [+keyid=newkey] [-keyid=oldkey]`, where `keyid` can only be used when `encryption` is either `hybrid` (default) or `pubkey`. + +This would break compatibility with the current interpretation of `encryption`, but I believe it's not so invasive: People are not creating new remotes every day, and an error message could clarify the new behavior. It's also clearer, since key IDs can be added and deleted at will, whereas the encryption scheme cannot. +"""]] -- cgit v1.2.3