1 |
On Sun, 13 Dec 2015 22:20:01 +0300 |
2 |
Andrew Savchenko <bircoph@g.o> wrote: |
3 |
|
4 |
> Hi, |
5 |
> |
6 |
> On Sun, 13 Dec 2015 18:36:51 +0100 Patrick Lauer wrote: |
7 |
> > Oh hey. We're in the future. Let's try to commit something to |
8 |
> > repo/gentoo.git! |
9 |
> > |
10 |
> > So apparently we're signing things with gpg now, so let's read the |
11 |
> > official documentation. |
12 |
> > The [1] wiki seems to be the canonical location for such things. |
13 |
|
14 |
... |
15 |
|
16 |
> > Since signing is mandatory since the git migration, ahem, this means |
17 |
> > that no one in the last 5 months(!) actually followed the |
18 |
> > documentation (because that does NOT work!). I'm almost impressed, |
19 |
> > but, wow, this is enterprisey. |
20 |
> |
21 |
> It is absolutely possible to create correct gpg key, put it into |
22 |
> LDAP according to GLEP and to sign commits and pushes properly. |
23 |
> What is not currently possible is to verify all tree automatically. |
24 |
> |
25 |
> I agree that gkeys needs more work. But we are all volunteers here. |
26 |
> You may help them if you are that interested into this |
27 |
> functionality. |
28 |
> |
29 |
> What worries me more that we still have no way for rsync users to |
30 |
> verify the portage tree (or Gentoo tree in the newspeak someone |
31 |
> prefers here). And most users use rsync. |
32 |
> |
33 |
> > So, what can we do to make this whole story of 'commit (and push) to |
34 |
> > repo/gentoo.git' make sense? And why do I appear to be the only one |
35 |
> > to notice this chain of breakage?! |
36 |
> |
37 |
> We need to complete gkeys project, right? That's not all of the |
38 |
> story, but a start. So send patches :) As for the full story, we |
39 |
> still need to somehow verify rsync tree. For now only snapshots are |
40 |
> verified. |
41 |
> |
42 |
> Best regards, |
43 |
> Andrew Savchenko |
44 |
|
45 |
Thank you Andrew. |
46 |
|
47 |
Let me first say, that while I am leading the gentoo-keys project. I |
48 |
have not been doing much with making progress to get another release |
49 |
out. My time is mostly taken up by full time work, add some health |
50 |
issues (not serious), plus with coding full time now (it was just a |
51 |
hobby before). I am finding it difficult to switch codebases to keep |
52 |
development going in a non work project. There is a certain amount of |
53 |
time needed to get back into the code to make any significant progress. |
54 |
|
55 |
But, one of the biggest things keeping me from doing more work on it |
56 |
when I do have some time, is the fact that barely any of the devs seem |
57 |
to care (other than the OP, who just seems to bitch about everything |
58 |
not working for him). Since the GLEP 63 spec has been approved. |
59 |
Barely any of the gentoo developers have even tried to update their gpg |
60 |
key or generate a new one that does meet the spec. For that reason, I |
61 |
have not endeavored to get more done in it. I've been trying to |
62 |
keep the gentoo-devs seed file reasonably up to date, but since there |
63 |
are few devs actually fixing or generating new keys, it is not needed |
64 |
that often. In fact weeks go by before there is a change in LDAP in |
65 |
regards to gpg keys. |
66 |
|
67 |
As Andrew pointed out in another reply, there is a fairly decent |
68 |
document about generating new gpg keys either directly using gpg or |
69 |
using gkeys-gen (gkeys-gen-9999) has the most troublesome bugs fixed in |
70 |
it btw). |
71 |
|
72 |
But lets get back to the OP's gpg keys. |
73 |
|
74 |
dolsen@vulture /var/lib/gkeys $ gkeys spec-check -C gentoo-devs -n patrick |
75 |
|
76 |
Checking keys... |
77 |
|
78 |
|
79 |
patrick, Patrick Lauer: 0x10F17899A28441CC, 0xA8447784E52864CE |
80 |
============================================== |
81 |
|
82 |
---------- |
83 |
Fingerprint......: 0A0901B8F018D5D6A4A31A4410F17899A28441CC |
84 |
Key type ........: PUB Capabilities.: sc |
85 |
Algorithm........: Pass Bit Length...: Fail |
86 |
Create Date......: Pass Expire Date..: Pass |
87 |
Key Version......: Pass Validity.....: e, Expired |
88 |
Days till expiry.: 0 |
89 |
Capability.......: Pass |
90 |
Qualified ID.....: Fail <== '@gentoo.org' user id not found |
91 |
This primary key.: Fail |
92 |
|
93 |
---------- |
94 |
Fingerprint......: 043F1AB5B35382E666BDBEA4058F9332F0BAE0B1 |
95 |
Key type ........: SUB Capabilities.: e |
96 |
Algorithm........: ---- Bit Length...: ---- |
97 |
Create Date......: Pass Expire Date..: Pass |
98 |
Key Version......: Pass Validity.....: e, Expired |
99 |
Days till expiry.: 0 |
100 |
Capability.......: Pass |
101 |
Qualified ID.....: Fail <== '@gentoo.org' user id not found |
102 |
This subkey......: Fail |
103 |
|
104 |
Key summary |
105 |
primary..........: Fail signing subkey: Fail |
106 |
encryption subkey: No authentication subkey: No |
107 |
SPEC requirements: Fail |
108 |
|
109 |
|
110 |
---------- |
111 |
Fingerprint......: F941D86BAA0D851BFE411493A8447784E52864CE |
112 |
Key type ........: PUB Capabilities.: scaESCA |
113 |
Algorithm........: Pass Bit Length...: Fail |
114 |
Create Date......: Pass Expire Date..: Fail |
115 |
Key Version......: Pass Validity.....: -, Unknown |
116 |
Days till expiry.: infinite <== Exceeds specification |
117 |
Capability.......: Pass |
118 |
Qualified ID.....: Pass |
119 |
This primary key.: Fail |
120 |
|
121 |
---------- |
122 |
Fingerprint......: 8FE9C051CD0859ED2E03274104711EEBFBF3D64A |
123 |
Key type ........: SUB Capabilities.: e encrypt |
124 |
Algorithm........: ---- Bit Length...: ---- |
125 |
Create Date......: Pass Expire Date..: Fail |
126 |
Key Version......: Pass Validity.....: -, Unknown |
127 |
Days till expiry.: infinite <== Exceeds specification |
128 |
Capability.......: Pass |
129 |
Qualified ID.....: Pass |
130 |
This subkey......: Fail |
131 |
|
132 |
Key summary |
133 |
primary..........: Fail signing subkey: Fail |
134 |
encryption subkey: Yes authentication subkey: No |
135 |
SPEC requirements: Fail |
136 |
|
137 |
|
138 |
|
139 |
No signing capable subkey: |
140 |
Patrick Lauer <patrick>: 0A0901B8F018D5D6A4A31A4410F17899A28441CC |
141 |
Patrick Lauer <patrick>: F941D86BAA0D851BFE411493A8447784E52864CE |
142 |
|
143 |
|
144 |
No Encryption capable subkey (Notice only): |
145 |
Patrick Lauer <patrick>: 0A0901B8F018D5D6A4A31A4410F17899A28441CC |
146 |
|
147 |
|
148 |
Incorrect bit length: |
149 |
Patrick Lauer <patrick>: 0A0901B8F018D5D6A4A31A4410F17899A28441CC |
150 |
Patrick Lauer <patrick>: F941D86BAA0D851BFE411493A8447784E52864CE |
151 |
|
152 |
|
153 |
Expiry keys: |
154 |
Patrick Lauer <patrick>: 8FE9C051CD0859ED2E03274104711EEBFBF3D64A |
155 |
Patrick Lauer <patrick>: F941D86BAA0D851BFE411493A8447784E52864CE |
156 |
|
157 |
|
158 |
Failed to pass SPEC requirements: |
159 |
Patrick Lauer <patrick>: 0A0901B8F018D5D6A4A31A4410F17899A28441CC |
160 |
Patrick Lauer <patrick>: F941D86BAA0D851BFE411493A8447784E52864CE |
161 |
|
162 |
|
163 |
Gkey task results: |
164 |
|
165 |
Found Failures: |
166 |
------- |
167 |
Revoked................: 0 |
168 |
Invalid................: 0 |
169 |
No Signing subkey......: 2 |
170 |
No Encryption subkey...: 1 |
171 |
Algorithm..............: 0 |
172 |
Bit length.............: 2 |
173 |
Expiry.................: 2 |
174 |
Expiry Warnings........: 0 |
175 |
SPEC requirements......: 2 |
176 |
============================= |
177 |
SPEC Approved..........: 0 |
178 |
|
179 |
dolsen@vulture /var/lib/gkeys $ |
180 |
|
181 |
|
182 |
Like so many of the dev's gpg keys, they can not ever meet the new spec |
183 |
because the bit length of the keys are unsatisfactory and proven to be |
184 |
crackable. Of which, both of his 2 registered (in LDAP) gpg keys are |
185 |
still the insecure type. At least his first one is now expired, but he |
186 |
has not attempted to remove it from LDAP, hmm... |
187 |
|
188 |
Since he has in the past generated gpg keys on 2 separate occasions, |
189 |
You would think he should be able to generate a new gpg key that does |
190 |
meet the GLEP 63 spec. But we have not seen any change in gpg keys |
191 |
nor had requests for help. Just complaints. I'm sorry, but I'm not |
192 |
volunteering my time to things in Gentoo just because I want to please |
193 |
someone that lately just seems to bitch and moan about things not being |
194 |
a single button or keypress fixable for him. |
195 |
|
196 |
We have offered help to devs many times in the past, but few have taken |
197 |
us up on it and fixed or generated a new gpg key. It has been my |
198 |
contention these past few months that the only way to get devs to fix |
199 |
their gpg keys or generate new ones will be to enforce GLEP 63 approved |
200 |
gpg keys for commit access. I know, that will almost completely |
201 |
stall out progress in the gentoo tree for a while. But it seems that |
202 |
is the only way many people will get off their ass and finally do |
203 |
something about it. |
204 |
|
205 |
|
206 |
As for gkeys integration into portage to be able to verify the |
207 |
manifests. It was not difficult, I had preliminary code working in it |
208 |
in just a few days for both portage and pkgcore. It would use gkeys to |
209 |
do the verification since it controlled the gpg key directories and |
210 |
keyrings. Both Zac and Tim said the tie ins should be done a little |
211 |
differently, but I still had code that did the job. I have a gpg |
212 |
wrapper script that git can be configured to use instead of gpg |
213 |
directly. That way it can use the gkeys keyring system. GPG still |
214 |
does the verification work, gkeys just controls the keyrings it sees) |
215 |
One of the things preventing it from mainstream was properly wrapping |
216 |
only the verify, but re-spawn ggp to do any signing (signed commits) |
217 |
without interference from any of gkeys. I believe I have that done |
218 |
now, but it has not been through enough testing to go into a release. |
219 |
It is very close I think. So volunteers please emerge gkeys-9999 and |
220 |
test the gkeys-gpg script and libs. I need to finish up a few more |
221 |
re-writes of a few more maintenance actions to follow the rest of the |
222 |
code changes Pavlos did as part of his GSOC project work. It should |
223 |
then be ready for another release. There have been some changes in the |
224 |
newest versions of gpg that I have been coming across. I am updating |
225 |
pyGPG to handle them as I discover them. So if anyone testing the live |
226 |
version find one, please report it with the traceback so we can update |
227 |
the code for it. |
228 |
|
229 |
Sorry in advance for spouting off some, but I found Patrick's original |
230 |
post in this thread quite offensive. After all a first release of |
231 |
gkeys-0.1 of a new developing code base had some bugs once tested on a |
232 |
wider machine and user base. Oh my, that has never happened before in |
233 |
the history of computing!!!! |
234 |
|
235 |
Patrick, I think it's time you put up or shut up. Bringing up |
236 |
shortcomings or other things that need attention is useful, but your |
237 |
near constant bitching is quite tiresome. You could start by fixing |
238 |
your own gpg key situation. If you don't find adequate documentation |
239 |
to do it, then create a some that does meets your satisfaction. |
240 |
|
241 |
|
242 |
-- |
243 |
Brian Dolbec <dolsen> |