From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-87056-garchives=archives.gentoo.org@lists.gentoo.org>
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 B105E138334
	for <garchives@archives.gentoo.org>; Thu, 25 Apr 2019 22:27:03 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 3E4A8E08E5;
	Thu, 25 Apr 2019 22:27:00 +0000 (UTC)
Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182])
	(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 DD3F7E08B0
	for <gentoo-dev@lists.gentoo.org>; Thu, 25 Apr 2019 22:26:59 +0000 (UTC)
Received: by mail-pl1-f182.google.com with SMTP id t16so508582plo.0
        for <gentoo-dev@lists.gentoo.org>; Thu, 25 Apr 2019 15:26:59 -0700 (PDT)
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:cc;
        bh=CTG2YkCDsbmM1vOvREZEA6DaQrCwzZWiYFHsaMC+JSo=;
        b=DeIya0s8aWdxUS1+1xHVUkPZ8NAEU2WGNK80JAQobH1dypaGTDAgu7/VRED7o9f4RI
         ZL07jcNJk4Kz8HFM7nMAq3hkWUQ91cMLLFyyA/Sa1TCcN4h0FK9n1+GUCEnkxVDbhF7t
         94huYm2xpcG8Y9tIEIdWKhuolIsaMV7A90ySy2GwWg7n/mO07sISkvoUUJwis0M8/yaZ
         861lMYklDZjo9Xc/rR//fExiJzi+TFTnXM8EVMyLp/G+vIm09SRR69lzwGpW1Ec3ZJ7w
         oQAZWvdXWkj0dbkl9typYMsT4Y/hg80svu1MQ1Bp9ebdxTcAhkJF9bR1sUQClvaMVNa+
         oWWg==
X-Gm-Message-State: APjAAAVXv3E5cTga31mCqv3j3Xa7d422YwHgKnNErPJunQ22N2bgG0ih
	f0cPUda8ntKAfHSRHY50dHq5C0I0eOpaOYGY/Kcsgd93
X-Google-Smtp-Source: APXvYqw57pS9qE1RylwTDNPSR2AtKqbJLoYKwqufYn//8QjPWL5jKGYHKPMpFq7VGX6Zfr4rXUQ2+6ZV0qGD/qDSDPA=
X-Received: by 2002:a17:902:396a:: with SMTP id e39mr42021762plg.220.1556231218301;
 Thu, 25 Apr 2019 15:26:58 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
MIME-Version: 1.0
References: <CAGfcS_=HEZhfXB0_iKc3NsdXwfyxA1g6pEm=-T2VMat-kJJa9Q@mail.gmail.com>
 <06a18165-fcb1-66bd-b9c0-b4dad4c30b8d@gentoo.org> <CAGfcS_mWUTN3NZiLaEotqnxGj8VZGDAq4cU7-8yJRbU2favhQQ@mail.gmail.com>
 <df2fa9aa-e425-0155-4d68-01225216cfe4@gentoo.org> <CAGfcS_nv4A936WFJZOzcJ7dqKOya7+ZO2Gh3pHo-KSeyE=b4GA@mail.gmail.com>
 <2fe69064-d22a-58c0-a624-6928df71a458@gentoo.org> <CAAr7Pr_wc1MsWi6co_nWmGjFzxp5Jf8Dgt-CYSk5i=Qj0rrvRw@mail.gmail.com>
 <20190425213417.7ab6d0e7@symphony.aura-online.co.uk> <CAGfcS_=+=wN4fu6rv4jdnfWAGY4axW97XgENPPiWnDq5m-cS_Q@mail.gmail.com>
 <e058fe3a-a163-ba61-4c68-6939b93a95ee@gentoo.org>
In-Reply-To: <e058fe3a-a163-ba61-4c68-6939b93a95ee@gentoo.org>
From: Rich Freeman <rich0@gentoo.org>
Date: Thu, 25 Apr 2019 18:26:46 -0400
Message-ID: <CAGfcS_=EgvcWvqypmEd14QRQqTQcvZsjnOxKVtxO7Qfn4e0u+Q@mail.gmail.com>
Subject: Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
To: Kristian Fiskerstrand <k_f@gentoo.org>
Cc: gentoo-dev <gentoo-dev@lists.gentoo.org>
Content-Type: text/plain; charset="UTF-8"
X-Archives-Salt: 6f5fa453-28f2-48c2-886d-2db980ff60da
X-Archives-Hash: 53ab65a2ec6b43d6845a92d14a774a8e

On Thu, Apr 25, 2019 at 4:55 PM Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>
> Quite frankly I'd expect a Gentoo Developer to be able to manage the gpg
> interface.
>

Being able to is not the same as caring enough to be bothered with
it...  I don't want to custom-tailor my Gentoo key.  I just want to
generate a key that will make the commit scripts happy.  The key is
completely disposable from a personal standpoint - when the GLEP was
recently revised to make my old key no longer valid, I just generated
a new one.  I didn't even bother revoking the old one, since it had no
function as soon as I changed the fingerprint in LDAP.

I was generating PGP keys back when it used idea and I'm guessing md5.
I've had gpg keys for decades.  I used my personal one for Gentoo
until the point where there were specific requirements for a Gentoo
key, and rather than try to personally live with the Gentoo
requirements it makes far more sense to just generate a
Gentoo-specific key.  Then we can change the GLEP as often as we like
it it really doesn't bother me much.  I can just discard my key and
create a new one, though it would be nice if those creating the GLEPs
would actually document the simplest way to do this for those who
really can't be bothered to read the man page.

I mean, I'd expect any Gentoo dev to be able to figure out how to use
git as well, but git also has a terrible command line interface, so
rather than put a bunch of requirements in a document and force
everybody to dig through manpages to get it to generate signed
commits/pushes/etc we just give a handy workflow.  After all, our goal
is to maintain the repo, not spend all day independently decipering
how to sign pushes or figuring out that a commit sig and a push sig
are two different things.

Personally I think we ought to make it easier to just use the
Nitrokeys we spent all this money on in a more secure manner than just
leaving primary keys lying around on hard drives, which is where I
suspect the vast majority will reside, completely negating the expense
the Foundation and Nitrokey both went through to provide them for us.
While I'm all for GLEPs themselves sticking to specs, having a
workflow document to go along with it would go a long way to helping
devs to comply, rather than spending all our effort writing
increasingly clever scripts to yell at them when they aren't
complying.

-- 
Rich