1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
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...
"""]]
|
