From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 15BE0138334 for ; Tue, 19 Feb 2019 23:21:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DAF96E083D; Tue, 19 Feb 2019 23:21:28 +0000 (UTC) Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9A65AE0839 for ; Tue, 19 Feb 2019 23:21:28 +0000 (UTC) Received: by mail-pf1-f169.google.com with SMTP id c123so10955003pfb.0 for ; Tue, 19 Feb 2019 15:21:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=VgCbQTBhbsUBkWDQyupsuPGlm/uY1s4EthxHwJAOjbs=; b=kGvlx+3my8Odtcngx51G/Q6AT4FhPdr5zATgqUa3asFi802cOVmUViIHAUjP5aDPC3 Ei6Pit7u9Be2ZEpmvXtPD6Q4gVlRVRj60VOigcTINGhEwSydrEwuDe/fPbFAz6KFD9Vd L3wJSw+avalvzzywlXYwRxV/TXYdjh0bex09Xbz7QNmGUx8FtXt+B6ChvIybSJb1kRs3 edxrlI50jiNvQddUhOjGOEX4TedFpBbI0XiavCAbO3Xejl+w4y7DDIP3TmA9Rf09eDk7 k9pnzaVkDXoe6x0+gvNSMyMWiHXM3Bfxb940tIJ/hgVyR5eIO+x2zakHaRoDALOyXwkm Maww== X-Gm-Message-State: AHQUAuYlwNRqt7QjxjDE74QqOltgj6/JXb9ffeF6fpLBvAgEDmGt8VOw Ji8IpnWti0R9Q8Pt8HiraCVlfiylrKE4riMegSgPwGIj X-Google-Smtp-Source: AHgI3IaDoVpz3n2dEPn+/39nV5FfbYBj1WY90HE+Xa+nSfqiQfIYI4KaSCRzg8k/5T+wZdW88MEAJb7leIYe2AmS9dk= X-Received: by 2002:aa7:9289:: with SMTP id j9mr23075774pfa.130.1550618487029; Tue, 19 Feb 2019 15:21:27 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <1550306421.831.16.camel@gentoo.org> <1550393754.1257.5.camel@gentoo.org> <20190217185416.nbgwm266moyk6j2u@gentoo.org> <1550496176.727.9.camel@gentoo.org> <1550606478.912.10.camel@gentoo.org> In-Reply-To: From: Rich Freeman Date: Tue, 19 Feb 2019 18:21:15 -0500 Message-ID: Subject: Re: [gentoo-project] [RFC] OpenPGP Authority Keys to provide validity of developer/service keys To: gentoo-project Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 22159585-f96f-4ddf-abfb-27fe7b2604ff X-Archives-Hash: 54e9c269a477619c14421370522053ab On Tue, Feb 19, 2019 at 4:54 PM Alec Warner wrote: > On Tue, Feb 19, 2019 at 3:16 PM Rich Freeman wrote: >> >> Now it is sounding like a proposal that both requires manual >> participation, and may also require manual updating, to avoid >> undertaking. > > > The authority scheme is *already* in use today. I'm referring to the need to do CAFF, not the need to have a gpg key in LDAP. > With CAFF, the attacker has more work to do because CAFF will make > the attacker show ownership of the private portion of the keypair > before we grant it authority. This has some benefit as it makes it > more likely for the attacker to make a mistake and get caught, or > leave a trail for us to find. If they fail CAFF (e.g. use the wrong > key) or commit without a CAFF key, we can use those as signals to > detect tampering and intrusion. Why would an attacker replace a key in LDAP with one they don't control? If they control LDAP, then they control the @gentoo.org email address already, should they exercise this control. That means they can redirect the email, change the key, obtain their signature, and upload their signature. That is more steps, but not more security. >> It seems like it would make far more sense to look at other direct >> measures of activity than how up-to-date their gpg key is in the >> keyservers. > > 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. Updating your keys is a one-liner with a shell script. It doesn't not require messing with emails. Sure, shell-scripting email isn't impossible, but I don't see what value it adds. You can already test whether devs are updating their gpg keys or not without messing with CAFF. > > Where should we set the bar here, if not "please contribute at least 30 minutes every year to retain your developership." How about doing ACTUAL activity? Not make-work? If somebody is actually doing commits in the tree, you know they're active and don't need them to jump through some additional hoops. And of course there are other types of activity where git signing keys aren't needed, and thus those hoops don't even add value in the first place, and where that other activity could be measured (number of forum logins/posts/whatevers, and so on). > >> >> Also, as far as I'm aware GLEP 63 does not require an encryption key >> at all, just a signing key. I'm not sure if such signing-keys will be >> signed by Gentoo under this proposal. If not then there is nothing to >> upload to the keyserver, and in any case it seems like the main use >> case of this (sending encrypted email) would not apply. Of course it >> could still be used for verifying email signatures if we sign >> signing-only keys. > > This does seem like a gap. > Only if you make it into one. If some dev has zero interest in receiving gpg-encrypted mail, encouraging people to gpg-encrypt mail to them just means that their mail goes to /dev/null, especially if they have their mail clients configured to auto-encrypt stuff. I mean, if I'm in infra and somebody needs to mail me the root keys to some box I can see the point in it, but 99% of what would get encrypted is stuff that could probably get by just being clear signed. -- Rich