blob: 92a454c187699156d406768a7832ce6777d6923e (
plain)
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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
|
### Please describe the problem.
Git-Annex enableremote ignores encryption changes to a hybrid-cypher gcrypt remote. So it is not possible to add or remove keys.
### What steps will reproduce the problem?
Having a bare repo prepared do:
git annex initremote $remotename type=gcrypt encryption=hybrid gitrepo=ssh://giessen@magierenklave.de/annex/test keyid=$myfirstkey
initremote $remotename (encryption setup) (to gpg keys: $myfirstkey) $user@$hosts's password:
(...)
git annex sync $remotename
(...)
git annex info $remotename
(...)
uuid: $remoteuuid
(...)
encryption: hybrid (to gpg keys: $myfirstkey)
(...)
git config --get remote.$remotename.gcrypt-participants
$myfirstkey
So far, so good. Now we try adding another key
git annex enableremote $remotename keyid+=$mysecondkey
enableremote $remotename ok
The command returns instantly, no interaction with the remote.
git annex sync $remotename
(...)
git annex info $remotename
(...)
uuid: $remoteuuid
(...)
encryption: hybrid (to gpg keys: $myfirstkey)
(...)
git config --get remote.$remotename.gcrypt-participants
$myfirstkey
Obviously our change had no effect. This can be verified by the repository being inaccessible to the second key.
A very hacky workaround seems to be:
git remote remove server.test
(we need this or git will complain about the remote already existing and annex will fail)
git annex enableremote $remoteuuid keyid+=$mysecondkey
enableremote $remoteuuid (encryption update) (to gpg keys: $myfirstkey $mysecondkey) $user@$hosts's password:
(...)
git annex info $remotename
(...)
encryption: hybrid (to gpg keys: $myfirstkey $mysecondkey)
(...)
git config --get remote.$remotename.gcrypt-participants
$myfirstkey $mysecondkey
...which yields the expected results but is somewhat counterintuitive and probably a bad abuse of enableremote.
### What version of git-annex are you using? On what operating system?
git annex version:
git-annex version: 6.20170302-gb35a50cca
build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
local repository version: 6
supported repository versions: 3 5 6
upgrade supported from repository versions: 0 1 2 3 4 5
operating system: linux x86_64
uname -a
Linux $host.$domain 4.9.3-1-default #1 SMP PREEMPT Thu Jan 12 11:32:53 UTC 2017 (2c7dfab) x86_64 x86_64 x86_64 GNU/Linux
### Please provide any additional information below.
gpg is running with -vvv so please don't mind the extra-verbose gpg-output.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
:~/test> git annex enableremote test keyid+=$mysecondkey
enableremote test ok
:~/test> git remote remove test
:~/test> git annex enableremote 1291d1b4-dac1-5c44-b09e-e04c03b755d6 keyid+=$mysecondkey
enableremote 1291d1b4-dac1-5c44-b09e-e04c03b755d6 (encryption update) (to gpg keys: $myfirstkey $mysecondkey) user@server's password:
gcrypt: Decrypting manifest
gpg: Signatur vom Mi 22 Mär 2017 14:50:39 CET
gpg: mittels RSA-Schlüssel 0144XXXXXXXXXXXXXXXXXXXXXXX
gpg: Korrekte Signatur von "XXXXXX" [ultimativ]
gcrypt: Remote ID is :id:Zfhze/U8YGNRIWmfNUV5
Von gcrypt::ssh://user@server/annex/test
* [neuer Branch] synced/git-annex -> test/synced/git-annex
* [neuer Branch] synced/master -> test/synced/master
* [neuer Branch] git-annex -> test/git-annex
* [neuer Branch] master -> test/master
user@server's password:
gcrypt: Decrypting manifest
gpg: Signatur vom Mi 22 Mär 2017 14:50:39 CET
gpg: mittels RSA-Schlüssel 0144XXXXXXXXXXXXXXXXXXXXXX
gpg: Korrekte Signatur von "XXXXXX" [ultimativ]
Everything up-to-date
user@server's password:
ok
ok
(recording state in git...)
# End of transcript or log.
"""]]
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Yes, definitively. I enjoy using annex to backup and manage my data. I would love to see it used more often and am currently trying to get my boss to introduce it for storage of the digital backups of our documents. While preparing an encrypted test-setup I stumbled upon this. :)
Thanks
Jörn
> [[fixed|done]] --[[Joey]]
|
