From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Q32mG-0000aZ-Oh for garchives@archives.gentoo.org; Fri, 25 Mar 2011 08:53:52 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CFC8CE079C; Fri, 25 Mar 2011 08:53:43 +0000 (UTC) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.180]) by pigeon.gentoo.org (Postfix) with ESMTP id E28CDE073A for ; Fri, 25 Mar 2011 08:53:12 +0000 (UTC) X-RZG-AUTH: :IW0NeWCpcPchHrcnS4ebzBgQnKHTmUiSF2JlOcyy/54wX4oRGP6NKj4cDg== X-RZG-CLASS-ID: mo05 Received: from pinacolada.localnet ([81.27.171.130]) by post.strato.de (jimi mo54) (RZmta 25.8) with ESMTPA id N02a5cn2P7g9no for ; Fri, 25 Mar 2011 09:53:11 +0100 (MET) From: "Andreas K. Huettel" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: rejecting unsigned commits Date: Fri, 25 Mar 2011 09:53:01 +0100 User-Agent: KMail/1.13.6 (Linux/2.6.36-gentoo-r5; KDE/4.6.1; x86_64; ; ) References: <20110325074824.TAf2c206.tv@veller.net> In-Reply-To: <20110325074824.TAf2c206.tv@veller.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5107702.JWqe33WSMH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201103250953.19757.dilfridge@gentoo.org> X-Archives-Salt: X-Archives-Hash: b06f6f96a2d4106d58ba29dfe12cd5d3 --nextPart5107702.JWqe33WSMH Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=20 > Do you want to reject signed commits if > - keys are not publicly available [1] Yes, since that defies the purpose of the signature. > - signatures are from expired keys [2] Yes if the signature was made after expiration. (Dont know if that is even= =20 possible.) No if the signature was made while the key was valid. (Otherwise our whole= =20 portage tree would time out at some point.) > - keys are revoked [3] Yes. > - keys are not listed in userinfo.xml (current or former devs) [4] Yes.=20 However, for the former devs we might need an extra list to prevent=20 "expiration on retirement", and treat the keys as if they expired on=20 retirement date (compare above). Does that make sense? Of course now we can add additional requirements: * The key must have an userid that refers to an official Gentoo e-mail=20 address. E.g. dilfridge@gentoo.org Very important and easily implemented. * The userid should have some specific "default string" in its comment fiel= d,=20 like "Gentoo manifest signing key". Not so important but also easily implemented. * The key should be signed by some central instance for automated validity= =20 check. Here things get hairy. How about having recruiter/infra team sign a dev's k= ey=20 on completion of the recruitment process? Just a first thought... * The central instance should be able to reliably revoke a key. Add a revocation list in a portage tree directory? Or is this just shooting= =20 yourself into the foot backwards through the eye? Cheers, A =2D-=20 Andreas K. Huettel Gentoo Linux developer=20 dilfridge@gentoo.org http://www.akhuettel.de/ --nextPart5107702.JWqe33WSMH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEABECAAYFAk2MV/8ACgkQ3ao2Zwy3NWqQIQCeOj+OdXNu0Okp05MA5e5N2mkU zJQAn0iYR4XoZyM8eVo7qXOdgF1IcsvG =5XDo -----END PGP SIGNATURE----- --nextPart5107702.JWqe33WSMH--