From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id +Kj2En0922AAZgEAgWs5BA (envelope-from ) for ; Tue, 29 Jun 2021 17:34:21 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id gG2zDn0922AMHAAAB5/wlQ (envelope-from ) for ; Tue, 29 Jun 2021 15:34:21 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id DA96B21D61 for ; Tue, 29 Jun 2021 17:34:20 +0200 (CEST) Received: from localhost ([::1]:56370 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lyFkh-0006Ss-JL for larch@yhetil.org; Tue, 29 Jun 2021 11:34:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42390) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lyFkD-0006SX-7F for guix-devel@gnu.org; Tue, 29 Jun 2021 11:33:49 -0400 Received: from tobias.gr ([2a02:c205:2020:6054::1]:58388) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lyFkA-0000j0-Ho for guix-devel@gnu.org; Tue, 29 Jun 2021 11:33:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=2018; bh=9mDMBe+O0MK2g +MnZNYfV6HmHxfhagxnhrQv0KTYXYM=; h=in-reply-to:date:subject:cc:to: from:references; d=tobias.gr; b=f2gga7ToJ+Y2apFbNeELOfE4EW2qjbvYzrSsGV JcLldO1u4f+C/fg0zX5B6gm3XAO1d39sN1Yc+bfyN4Qk+dgBBq8ghXsMytXqDH3H8ddIdd xMo3+9mdYeWKzAVwhafNisXSBw7fvx2BRg2yBgpIKL4op2kt79fUg5AAJnQN96d5iaXC6p FONYPYNHOKbqji9wybj4pEvhUO0qEk0a7GFY3c0mQW81CzuPcO1x0Nd9t+/NSX2pBCCuPT fTU/Fe72Mfi7cbGtWW2s15PsKFtbqvzQL+Ji7zE/kU0F+4dMvKuvo/PPrS+HBrqXCirHw3 XR+ICM0N76ORM/dv58PT/zyg== Received: by submission.tobias.gr (OpenSMTPD) with ESMTPSA id 24306222 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Tue, 29 Jun 2021 15:33:38 +0000 (UTC) References: <124ad5525164ec009000a9fad5c9dad23e68929d.camel@posteo.net> <871r8sy9n2.fsf@gnu.org> <87wnqcrbdm.fsf@gnu.org> From: Tobias Geerinckx-Rice To: Eric Bavier Cc: guix-devel@gnu.org Subject: Re: New signing key Date: Tue, 29 Jun 2021 16:40:35 +0200 In-reply-to: <87wnqcrbdm.fsf@gnu.org> BIMI-Selector: v=BIMI1; s=default; Message-ID: <87eeckbs8d.fsf@nckx> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=2a02:c205:2020:6054::1; envelope-from=me@tobias.gr; helo=tobias.gr X-Spam_score_int: -1 X-Spam_score: -0.2 X-Spam_bar: / X-Spam_report: (-0.2 / 5.0 requ) BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1624980861; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=9mDMBe+O0MK2g+MnZNYfV6HmHxfhagxnhrQv0KTYXYM=; b=jp/CHZboXSzgt14XrjoH2n0j2CeVi6nSzRryQ6LO7Ng5ssZWR/R0sADld0wMtkMvuzQyPU tEBujDjk3iF5SEuVYPehmwgEnOnbL1hcLsD+w7F/H11G/2kOeD6mjrUmbzybLTtPdiRTr1 A/V6kz3wUbJyb8SECYScCMgwvkDz+7O48tsno81affPtjUCLBMHi2AURsKrXnGswF4IFSe 1ikSFRxtKBI6gtI17+jA8nj1c/biOghIvHt+EQQcoYGke5Ih1CG8OvA/m0bEOPN8mNW/mA d4rqFg8Y+mshjOX87ic/FxuKc/46EkLqYl3D/HBccLhzTdr6AwsPc+Yvblezew== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1624980861; a=rsa-sha256; cv=none; b=E7coDIL+G0zvxsRIBaVP/2jwQSFsh7z6rmXfVETUOtToftP73VvnQ3OHqI/+KwhZuRa9cu 6Eg80Rod61UWVKOHTbSHDTok6nixEKgCRCSSGH73/bl0DMWbZRhk5R57ILqwvp3gpncO0m 1lCwLcT3eHIc/LFiujIM6t5R46SQ1cenQaoDqOwdBemh69rW/WttEtChVIej1Dnh5vNeJz lcV8Z3+uSlaZVQy8gN5xRpgEzISNYRDSk89hCIMIbaCK9xqcQi5vFLqmurKG6uAPx621jv 0p7+Nv1UPaPNRqX4Nv249usqlNlJ2Dtkr58GfNSYrkjgRKdRjQpHLK96ilv34Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=tobias.gr header.s=2018 header.b=f2gga7To; dmarc=pass (policy=reject) header.from=tobias.gr; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -4.72 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=tobias.gr header.s=2018 header.b=f2gga7To; dmarc=pass (policy=reject) header.from=tobias.gr; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: DA96B21D61 X-Spam-Score: -4.72 X-Migadu-Scanner: scn0.migadu.com X-TUID: Eb9/HczDv6eU --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Question: I think committers should be trusted with discretion in=20 how they prefer to manage their keys, but how about briefly=20 documenting a suggested sane key-management strategy to new=20 committers, like we already describe some rando's editor set-up?=20 :-) I don't think most people *insist* on their current one, it's just=20 what they know; and GPG is complex and gnarly. Eric Bavier skribis: > In this case, the old key had already expired. I think others=20 > here > have reset the expiry date on their keys before? Limiting validity to 1=E2=80=A62y is considered good hygiene, as is simply= =20 extending the date whenever it's about to expire. It proves you=20 still control the private key. It doesn't matter if you miss the=20 deadline. It's what I'd suggest for Guix because it gives committers full=20 control over renewal without the inherent risk of updating the=20 keyring & .guix-authorizations each time. It also makes such=20 commits less routine, which I think is good=E2=80=A6 > I like the idea of honoring the expiration dates I set Excellent, but ^ this=E2=80=A6 > and creating a new key. =E2=80=A6doesn't imply ^ this. Signing your existing key with a new expiry date is just as=20 honourable^Wsecure, and much less hassle. You would have avoided=20 the delay you encountered here. Others would get a better error=20 message (=E2=80=98expired=E2=80=99 vs. now =E2=80=98unknown=E2=80=99). Etc. I'm not aware of any authority on best practices that would claim=20 the opposite, but if you are, I'd be grateful to hear about it! Kind regards, T G-R --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCYNs9Ug0cbWVAdG9iaWFz LmdyAAoJEA2w/4hPVW15BwUBAK1kXfuwVsJplsm1srLrBy7XuofLpmmjhpDn/PdF r+M5AP9UlPA+NyQkOzi1NpTEnEHBjDT9OtUGYUvp5G9in+6RCA== =soMe -----END PGP SIGNATURE----- --=-=-=--