| 1 |
Andreas K. Huettel dixit (2011-03-25, 09:53): |
| 2 |
|
| 3 |
> > Do you want to reject signed commits if |
| 4 |
> > - keys are not publicly available [1] |
| 5 |
> |
| 6 |
> Yes, since that defies the purpose of the signature. |
| 7 |
> |
| 8 |
> > - signatures are from expired keys [2] |
| 9 |
> |
| 10 |
> Yes if the signature was made after expiration. (Dont know if that is even |
| 11 |
> possible.) |
| 12 |
> No if the signature was made while the key was valid. (Otherwise our whole |
| 13 |
> portage tree would time out at some point.) |
| 14 |
> |
| 15 |
> > - keys are revoked [3] |
| 16 |
> |
| 17 |
> Yes. |
| 18 |
> |
| 19 |
> > - keys are not listed in userinfo.xml (current or former devs) [4] |
| 20 |
> |
| 21 |
> Yes. |
| 22 |
> However, for the former devs we might need an extra list to prevent |
| 23 |
> "expiration on retirement", and treat the keys as if they expired on |
| 24 |
> retirement date (compare above). |
| 25 |
> |
| 26 |
> Does that make sense? |
| 27 |
> |
| 28 |
> Of course now we can add additional requirements: |
| 29 |
> |
| 30 |
> * The key must have an userid that refers to an official Gentoo e-mail |
| 31 |
> address. E.g. dilfridge@g.o |
| 32 |
> |
| 33 |
> Very important and easily implemented. |
| 34 |
> |
| 35 |
> * The userid should have some specific "default string" in its comment field, |
| 36 |
> like "Gentoo manifest signing key". |
| 37 |
> |
| 38 |
> Not so important but also easily implemented. |
| 39 |
> |
| 40 |
> * The key should be signed by some central instance for automated validity |
| 41 |
> check. |
| 42 |
> |
| 43 |
> Here things get hairy. How about having recruiter/infra team sign a dev's key |
| 44 |
> on completion of the recruitment process? Just a first thought... |
| 45 |
|
| 46 |
I think this is an important requirement however it's quite difficult |
| 47 |
to conduct reliably. A normal keysigning process usually requires |
| 48 |
knowing one personally (and perhaps verifying fingerprints over a |
| 49 |
phone with voice verification), seeing one's ID personally and the |
| 50 |
like. This is probably unfeasible in the Gentoo development |
| 51 |
environment (I'm not a dev, though, so I'm just guessing). |
| 52 |
|
| 53 |
As a weaker but possibly useful workaround Gentoo Infra could just |
| 54 |
publish a signed list of trusted developer keys for any given moment. |
| 55 |
|
| 56 |
> * The central instance should be able to reliably revoke a key. |
| 57 |
> |
| 58 |
> Add a revocation list in a portage tree directory? Or is this just shooting |
| 59 |
> yourself into the foot backwards through the eye? |
| 60 |
|
| 61 |
Revoking a signature on a key is possible (unless a key has been |
| 62 |
nrsigned) and makes sense (assuming those who verify update all |
| 63 |
relevant keys). |
| 64 |
|
| 65 |
-- |
| 66 |
[a] |
Archives