Gentoo Archives: gentoo-project

From: Thomas Deutschmann <whissi@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] [pre-GLEP RFC] New GLEP: Gentoo OpenPGP Authority Keys
Date: Sun, 10 Mar 2019 16:53:20
Message-Id: 9082869f-c172-35d9-0b46-5c2f963ed8f7@gentoo.org
In Reply to: [gentoo-project] [pre-GLEP RFC] New GLEP: Gentoo OpenPGP Authority Keys by "Michał Górny"
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies