From d8e24d5ddbf37b2e609e354a01a5ffebff89e957 Mon Sep 17 00:00:00 2001 From: guilhem Date: Fri, 16 Aug 2013 07:14:12 +0000 Subject: [PATCH] Added a comment --- ...ment_4_78b3c52ba85edfa6ee6e273bec3bea5c._comment | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 doc/bugs/Using_a_revoked_GPG_key/comment_4_78b3c52ba85edfa6ee6e273bec3bea5c._comment diff --git a/doc/bugs/Using_a_revoked_GPG_key/comment_4_78b3c52ba85edfa6ee6e273bec3bea5c._comment b/doc/bugs/Using_a_revoked_GPG_key/comment_4_78b3c52ba85edfa6ee6e273bec3bea5c._comment new file mode 100644 index 0000000000..61b03c1096 --- /dev/null +++ b/doc/bugs/Using_a_revoked_GPG_key/comment_4_78b3c52ba85edfa6ee6e273bec3bea5c._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="guilhem" + ip="129.16.20.209" + subject="comment 4" + date="2013-08-16T07:14:12Z" + content=""" +The [[OpenPGP standard|https://tools.ietf.org/html/rfc4880]] specifies that revoked keys/subkeys \"are not to be used\". AFIK GnuPG, as any RFC-compliant implementation, will not let you encrypt to a revoked key no matter what. An extremely dirty workaround is to set up your system clock prior to the revocation date (but that might put your whole system at risk since other applications may rely synced clocks to work properly). + +That said, what you really wanted to do was to revoke access to K1 and add K2 instead. That seems to be a perfectly valid use-case, and it shouldn't be hard to add to git-annex; stay tunned ;-) + + +Tobias: Not sure what you meant by \"revoke access to my annex\", but if you were thinking of the key owner, note that with the current [[encryption design|http://git-annex.branchable.com/design/encryption]], since that person may simply grab from the git repo and then at any time decrypt the passphrase for the symmetric cipher, it makes little sense to revoke access for that person unless you change that passphrase, and reencrypt all annexed files on the remote, which of course needs to be done locally for the encryption to make sense at all. +"""]]