Re: [gentoo-project] [pre-GLEP RFC] New GLEP: Gentoo OpenPGP Authority Keys

[Thomas Deutschmann]

Hi,

I know I am late but...

1) I still don't understand the motivation for this. What will
change/improve/be possible in future vs. status quo?

2) This sounds like a blackbox only a few people know/understand:

> +The single L1 Authority Key is used only to (manually) certify the L2
> +Keys, and is kept securely offline following the Infrastructure policies
> +on protecting primary keys.

However, the L1 key is critical, especially if all devs will sign that
key. E.g. this will allow people with access to L1 to establish a new
tree without the knowledge of everyone who signed the key but the new
tree will be able to issue new signatures and everyone will accept them
because L1 is trusted. Unacceptable. Process must be clear for
_everyone_. No blackbox.


> +The fingerprint of this key is published
> +on the Gentoo website and users are requested to sign this key to enable
> +key validity via Authority Keys.

This is problematic. Nobody should ever sign something because it was
published somewhere. I know this will be a hard challenge but I believe
the L1 key can only be created if infra people will meet in person:

- This will guarantee that nobody will take a copy of the L1 key,
assuming we trust these people (maybe do this during a Gentoo conference
so other people can watch the ceremony).

- We will sign L1 only because it was signed by infra person X which we
met in person. E.g. nobody should sign L1 key who hasn't met anyone who
already signed that key. Because mgorny and antarus for example never
met somone else according to current WoT graph, trust anchor will
probably be robbat2 -> k_f -> ... for most people. But signing something
because you were asked to do so without *any* trust anchor should be a
no go.

My main criticisms, however, is that this system will create a false
sense of security (authenticity to be precise):

Let's say Gentoo has a developer named Bob.

Bob's local system will get compromised. Attacker will gain access to
Bob's SSH key and will also find Bob's Gentoo LDAP password.

With the SSH key, the attacker will be able to connect to
dev.gentoo.org. The LDAP password will allow the attacker to add or
replace Bob's GPG fingerprint.

Thanks to the new system, an automatic process will sign that new GPG key.

The attacker is now able to manipulate an ebuild for example and push
that change. If no one happens to review the commit for some reason and
notice the malicious change, attack will be successful, because the
commit has a valid signature.

That's basically status quo (see #1).

Once we detect the compromise, we would disable Bob's access and revoke
all signatures. But this doesn't matter anymore.

Also keep in mind that currently we only validate last commit. If
another developer will add his/her commit on top of the attacker's
change, the attacker's key doesn't matter anymore.

My point is, you cannot automate trust. Yes, if someone has to change
his/her key it will be a pain for everyone... but that's part of the
game. The difference would be that nobody would sign that new key the
attacker added to LDAP because it wasn't signed by Bob's previous key
everyone trusted. So everyone would ping Bob asking what's going on. If
this would be a legitimate key change, Bob would explain that (and
probably sign that new key with the old key or he would have to
establish a new WoT). If this wasn't a legitimate key change, we would
notice...

I am basically back at #1. Why do we need GLEP 79? It doesn't improve
anything for real aside adding a lot of complexity. Wrong?


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5