| 1 |
On Tue, Feb 19, 2019 at 4:54 PM Alec Warner <antarus@g.o> wrote: |
| 2 |
> On Tue, Feb 19, 2019 at 3:16 PM Rich Freeman <rich0@g.o> wrote: |
| 3 |
>> |
| 4 |
>> Now it is sounding like a proposal that both requires manual |
| 5 |
>> participation, and may also require manual updating, to avoid |
| 6 |
>> undertaking. |
| 7 |
> |
| 8 |
> |
| 9 |
> The authority scheme is *already* in use today. |
| 10 |
|
| 11 |
I'm referring to the need to do CAFF, not the need to have a gpg key in LDAP. |
| 12 |
|
| 13 |
> With CAFF, the attacker has more work to do because CAFF will make |
| 14 |
> the attacker show ownership of the private portion of the keypair |
| 15 |
> before we grant it authority. This has some benefit as it makes it |
| 16 |
> more likely for the attacker to make a mistake and get caught, or |
| 17 |
> leave a trail for us to find. If they fail CAFF (e.g. use the wrong |
| 18 |
> key) or commit without a CAFF key, we can use those as signals to |
| 19 |
> detect tampering and intrusion. |
| 20 |
|
| 21 |
Why would an attacker replace a key in LDAP with one they don't control? |
| 22 |
|
| 23 |
If they control LDAP, then they control the @gentoo.org email address |
| 24 |
already, should they exercise this control. That means they can |
| 25 |
redirect the email, change the key, obtain their signature, and upload |
| 26 |
their signature. That is more steps, but not more security. |
| 27 |
|
| 28 |
>> It seems like it would make far more sense to look at other direct |
| 29 |
>> measures of activity than how up-to-date their gpg key is in the |
| 30 |
>> keyservers. |
| 31 |
> |
| 32 |
> I'm bad at GPG. However, I believe updating my keys to adapt to the policy took me about 30 minutes. Its required once every 12 months. |
| 33 |
|
| 34 |
Updating your keys is a one-liner with a shell script. It doesn't not |
| 35 |
require messing with emails. Sure, shell-scripting email isn't |
| 36 |
impossible, but I don't see what value it adds. |
| 37 |
|
| 38 |
You can already test whether devs are updating their gpg keys or not |
| 39 |
without messing with CAFF. |
| 40 |
|
| 41 |
> |
| 42 |
> Where should we set the bar here, if not "please contribute at least 30 minutes every year to retain your developership." |
| 43 |
|
| 44 |
How about doing ACTUAL activity? Not make-work? |
| 45 |
|
| 46 |
If somebody is actually doing commits in the tree, you know they're |
| 47 |
active and don't need them to jump through some additional hoops. |
| 48 |
|
| 49 |
And of course there are other types of activity where git signing keys |
| 50 |
aren't needed, and thus those hoops don't even add value in the first |
| 51 |
place, and where that other activity could be measured (number of |
| 52 |
forum logins/posts/whatevers, and so on). |
| 53 |
|
| 54 |
> |
| 55 |
>> |
| 56 |
>> Also, as far as I'm aware GLEP 63 does not require an encryption key |
| 57 |
>> at all, just a signing key. I'm not sure if such signing-keys will be |
| 58 |
>> signed by Gentoo under this proposal. If not then there is nothing to |
| 59 |
>> upload to the keyserver, and in any case it seems like the main use |
| 60 |
>> case of this (sending encrypted email) would not apply. Of course it |
| 61 |
>> could still be used for verifying email signatures if we sign |
| 62 |
>> signing-only keys. |
| 63 |
> |
| 64 |
> This does seem like a gap. |
| 65 |
> |
| 66 |
|
| 67 |
Only if you make it into one. If some dev has zero interest in |
| 68 |
receiving gpg-encrypted mail, encouraging people to gpg-encrypt mail |
| 69 |
to them just means that their mail goes to /dev/null, especially if |
| 70 |
they have their mail clients configured to auto-encrypt stuff. |
| 71 |
|
| 72 |
I mean, if I'm in infra and somebody needs to mail me the root keys to |
| 73 |
some box I can see the point in it, but 99% of what would get |
| 74 |
encrypted is stuff that could probably get by just being clear signed. |
| 75 |
|
| 76 |
-- |
| 77 |
Rich |
Archives