1 |
> |
2 |
> Do you want to reject signed commits if |
3 |
> - keys are not publicly available [1] |
4 |
|
5 |
Yes, since that defies the purpose of the signature. |
6 |
|
7 |
> - signatures are from expired keys [2] |
8 |
|
9 |
Yes if the signature was made after expiration. (Dont know if that is even |
10 |
possible.) |
11 |
No if the signature was made while the key was valid. (Otherwise our whole |
12 |
portage tree would time out at some point.) |
13 |
|
14 |
> - keys are revoked [3] |
15 |
|
16 |
Yes. |
17 |
|
18 |
> - keys are not listed in userinfo.xml (current or former devs) [4] |
19 |
|
20 |
Yes. |
21 |
However, for the former devs we might need an extra list to prevent |
22 |
"expiration on retirement", and treat the keys as if they expired on |
23 |
retirement date (compare above). |
24 |
|
25 |
Does that make sense? |
26 |
|
27 |
Of course now we can add additional requirements: |
28 |
|
29 |
* The key must have an userid that refers to an official Gentoo e-mail |
30 |
address. E.g. dilfridge@g.o |
31 |
|
32 |
Very important and easily implemented. |
33 |
|
34 |
* The userid should have some specific "default string" in its comment field, |
35 |
like "Gentoo manifest signing key". |
36 |
|
37 |
Not so important but also easily implemented. |
38 |
|
39 |
* The key should be signed by some central instance for automated validity |
40 |
check. |
41 |
|
42 |
Here things get hairy. How about having recruiter/infra team sign a dev's key |
43 |
on completion of the recruitment process? Just a first thought... |
44 |
|
45 |
* The central instance should be able to reliably revoke a key. |
46 |
|
47 |
Add a revocation list in a portage tree directory? Or is this just shooting |
48 |
yourself into the foot backwards through the eye? |
49 |
|
50 |
Cheers, A |
51 |
|
52 |
-- |
53 |
|
54 |
Andreas K. Huettel |
55 |
Gentoo Linux developer |
56 |
dilfridge@g.o |
57 |
http://www.akhuettel.de/ |