Merge branch 'master' into database

9 files changed, 0 insertions, 124 deletions

diff --git a/doc/bugs/Using_a_revoked_GPG_key/comment_1_7bb01d081282e5b02b7720b2953fe5be._comment b/doc/bugs/Using_a_revoked_GPG_key/comment_1_7bb01d081282e5b02b7720b2953fe5be._comment
deleted file mode 100644
index baddbbf49..000000000
--- a/doc/bugs/Using_a_revoked_GPG_key/comment_1_7bb01d081282e5b02b7720b2953fe5be._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA"
- nickname="Tobias"
- subject="comment 1"
- date="2013-08-12T11:47:28Z"
- content="""
-I'd be very unhappy indeed if I couldn't revoke access to my annex.
-"""]]
diff --git a/doc/bugs/Using_a_revoked_GPG_key/comment_2_9c0c40360f0058a4bd346c1362e302b6._comment b/doc/bugs/Using_a_revoked_GPG_key/comment_2_9c0c40360f0058a4bd346c1362e302b6._comment
deleted file mode 100644
index 003f9a34a..000000000
--- a/doc/bugs/Using_a_revoked_GPG_key/comment_2_9c0c40360f0058a4bd346c1362e302b6._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://www.rfc1149.net/"
- nickname="Sam"
- subject="comment 2"
- date="2013-08-13T07:28:30Z"
- content="""
-Tobias: I don't understand what you mean. The issue here is that once an existing key is revoked, git-annex will refuse to add *another non-revoked* key.
-"""]]
diff --git a/doc/bugs/Using_a_revoked_GPG_key/comment_3_8f69f58107246595f5603f35c4aa7395._comment b/doc/bugs/Using_a_revoked_GPG_key/comment_3_8f69f58107246595f5603f35c4aa7395._comment
deleted file mode 100644
index 7f18cfe39..000000000
--- a/doc/bugs/Using_a_revoked_GPG_key/comment_3_8f69f58107246595f5603f35c4aa7395._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA"
- nickname="Tobias"
- subject="comment 3"
- date="2013-08-13T08:47:45Z"
- content="""
-Ah, sorry, i'm uncomprehending :)
-"""]]
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
deleted file mode 100644
index 61b03c109..000000000
--- a/doc/bugs/Using_a_revoked_GPG_key/comment_4_78b3c52ba85edfa6ee6e273bec3bea5c._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!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.
-"""]]
diff --git a/doc/bugs/Using_a_revoked_GPG_key/comment_5_a85ccf2f09ebe87147f8761b81a02326._comment b/doc/bugs/Using_a_revoked_GPG_key/comment_5_a85ccf2f09ebe87147f8761b81a02326._comment
deleted file mode 100644
index ff441671f..000000000
--- a/doc/bugs/Using_a_revoked_GPG_key/comment_5_a85ccf2f09ebe87147f8761b81a02326._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://www.rfc1149.net/"
- nickname="Sam"
- subject="comment 5"
- date="2013-08-19T11:35:52Z"
- content="""
-Indeed, removing the revoked key and putting the new one would be acceptable, there is no reason to keep the revoked one around.
-"""]]
diff --git a/doc/bugs/Using_a_revoked_GPG_key/comment_6_8b89eb5e6386acd0a922310c04f863ac._comment b/doc/bugs/Using_a_revoked_GPG_key/comment_6_8b89eb5e6386acd0a922310c04f863ac._comment
deleted file mode 100644
index eb9cd0f54..000000000
--- a/doc/bugs/Using_a_revoked_GPG_key/comment_6_8b89eb5e6386acd0a922310c04f863ac._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="guilhem"
- ip="129.16.20.209"
- subject="comment 6"
- date="2013-08-19T13:22:59Z"
- content="""
-All right, what would be a nice user interface, compatible with the current commands? I was thinking of something along the lines of `git annex enableremote +encryption=newKey -encryption=oldKey`, with an alias `+encryption=encryption` to be backward compatible. It's probably not optimal though, feel free to comment :-)
-
-Of course, `git-annex` should ensure that at any point in time the passphrase is always encrypted using an OpenPGP key. (Otherwise it might be stored clear in the git repository, which would void the encryption.) Also, anyone who can decrypt the passphrase can revoke all existing keys and reencrypt it using another key; this not really a big deal since the cipher is version-controlled anyway, so loosing access to the repo is unlikely.
-
-By the way, since we're about to amend the arguments for `enableremote`, it'd be nice to take advantage of the situation to allow pure asymmetric encryption. I propose `git annex initremote ... encryption=myKey crypto={none,hybrid,pubkey}` to use respectively no-encryption, an asymmetrically encrypted passphrase (the current design, default), and OpenPGP keys only.
-"""]]
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
deleted file mode 100644
index 02be72e36..000000000
--- a/doc/bugs/Using_a_revoked_GPG_key/comment_7_20dc5a7ce7cb6ca97ccdfb923c3b24bb._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!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.
-"""]]
diff --git a/doc/bugs/Using_a_revoked_GPG_key/comment_8_9dc921dc6077f828454a4444088b9a43._comment b/doc/bugs/Using_a_revoked_GPG_key/comment_8_9dc921dc6077f828454a4444088b9a43._comment
deleted file mode 100644
index a63ce1262..000000000
--- a/doc/bugs/Using_a_revoked_GPG_key/comment_8_9dc921dc6077f828454a4444088b9a43._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="4.154.0.63"
- subject="comment 8"
- date="2013-08-22T17:05:49Z"
- content="""
-Note that the assistant generates initremote parameters so code there also needs to be changed if the syntax changes.
-
-I think I am ok with changing the syntax. However, it seems that `encryption=-oldkey encryption=newkey` could be used to remove the old revoked key and add a new one. Using `-keyid` as a parameter to initremote is a bit tricky since git-annex's regular option parser would see it, before the parameter could get to initremote. (Unless -keyid was defined as a regular option specific to initremote.) OR, git-annex could just try to detect when a key is revoked and automatically remove it when a new encryption key is specified.
-
-Hmm, it would be possible to have it just notice, when adding a new key, if one of the existing keys is revoked, and
-remove the revoked key automatically.
-
-The above doesn't deal with the case of wanting to add pure asymmetric encryption. It seems to me that from a user's point of view, what they really need to know about asymmetric encryption is that they can't easily give additional keyids access after the fact (without reencrypting and reuploading everything). So I think it would be good if the syntax made that obvious. Perhaps `encryptiononly=key`
-"""]]
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...
-
-"""]]