| 1 |
On Tue, Feb 19, 2019 at 3:16 PM Rich Freeman <rich0@g.o> wrote: |
| 2 |
|
| 3 |
> On Tue, Feb 19, 2019 at 3:01 PM Michał Górny <mgorny@g.o> wrote: |
| 4 |
> > |
| 5 |
> > On Tue, 2019-02-19 at 19:47 +0000, Robin H. Johnson wrote: |
| 6 |
> > > |
| 7 |
> > > 3) would be good to detect on the less-active devs, and gives good |
| 8 |
> > > life-signs to undertakers. |
| 9 |
> > |
| 10 |
> > Maybe. However, we're practically talking about one-time check here. |
| 11 |
> > Once the key is initially signed (and if the developer ignores GLEP 63 |
| 12 |
> > expiration suggestions), there will be no reason to mail him again. |
| 13 |
> |
| 14 |
> Until now this has seemed like something that didn't require any |
| 15 |
> manual developer participation. |
| 16 |
> |
| 17 |
|
| 18 |
> Now it is sounding like a proposal that both requires manual |
| 19 |
> participation, and may also require manual updating, to avoid |
| 20 |
> undertaking. |
| 21 |
|
| 22 |
|
| 23 |
The authority scheme is *already* in use today. We currently allow any FP |
| 24 |
in LDAP with an @gentoo.org address to commit. This proposal just |
| 25 |
standardizes it using existing tooling so that users can consume the trust |
| 26 |
graph easily. The base proposal doesn't change any of the rules, just the |
| 27 |
implementation; to make it *easier* for end users to use the authority |
| 28 |
scheme. This is a net good for Gentoo, IMHO, as we should use and adopt |
| 29 |
standards of the time. Our current authority scheme doesn't use CAFF and |
| 30 |
does not verify gpg fingerprints in LDAP. |
| 31 |
|
| 32 |
CAFF addresses a deficiency in the current system. Currently we don't |
| 33 |
validate control over fingerprints in LDAP. This means once an attacker |
| 34 |
gains LDAP access, they only need to add a key fingerprint to an LDAP |
| 35 |
record in order to get their commits through the GPG verification process. |
| 36 |
|
| 37 |
With CAFF, the attacker has more work to do because CAFF will make the |
| 38 |
attacker show ownership of the private portion of the keypair before we |
| 39 |
grant it authority. This has some benefit as it makes it more likely for |
| 40 |
the attacker to make a mistake and get caught, or leave a trail for us to |
| 41 |
find. If they fail CAFF (e.g. use the wrong key) or commit without a CAFF |
| 42 |
key, we can use those as signals to detect tampering and intrusion. |
| 43 |
|
| 44 |
I consider CAFF to be important (as something we should do) but not a |
| 45 |
requirement (something we must do in order) in this implementation of the |
| 46 |
authority scheme. |
| 47 |
|
| 48 |
|
| 49 |
> |
| 50 |
> It seems like it would make far more sense to look at other direct |
| 51 |
> measures of activity than how up-to-date their gpg key is in the |
| 52 |
> keyservers. |
| 53 |
> |
| 54 |
|
| 55 |
I'm bad at GPG. However, I believe updating my keys to adapt to the policy |
| 56 |
took me about 30 minutes. Its required once every 12 months. |
| 57 |
|
| 58 |
Where should we set the bar here, if not "please contribute at least 30 |
| 59 |
minutes every year to retain your developership." |
| 60 |
|
| 61 |
|
| 62 |
> Also, as far as I'm aware GLEP 63 does not require an encryption key |
| 63 |
> at all, just a signing key. I'm not sure if such signing-keys will be |
| 64 |
> signed by Gentoo under this proposal. If not then there is nothing to |
| 65 |
> upload to the keyserver, and in any case it seems like the main use |
| 66 |
> case of this (sending encrypted email) would not apply. Of course it |
| 67 |
> could still be used for verifying email signatures if we sign |
| 68 |
> signing-only keys. |
| 69 |
> |
| 70 |
|
| 71 |
This does seem like a gap. |
| 72 |
|
| 73 |
-A |
| 74 |
|
| 75 |
|
| 76 |
> |
| 77 |
> -- |
| 78 |
> Rich |
| 79 |
> |
| 80 |
> |
Archives