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 <gentoo-dev+bounces-45000-garchives=archives.gentoo.org@lists.gentoo.org>) id 1Q3PYG-0008R8-WE for garchives@archives.gentoo.org; Sat, 26 Mar 2011 09:12:57 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 87ECE1C00F; Sat, 26 Mar 2011 09:12:46 +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 D58831C006 for <gentoo-dev@lists.gentoo.org>; Sat, 26 Mar 2011 09:12:11 +0000 (UTC) X-RZG-AUTH: :IW0NeWCpcPchHrcnS4ebzBgQnKHTmUiSF2JlOcyy/54wX4oRGP6NKj4cDg== X-RZG-CLASS-ID: mo05 Received: from pinacolada.localnet ([81.27.171.130]) by post.strato.de (klopstock mo42) (RZmta 25.8) with ESMTPA id J052f8n2Q3IJTE for <gentoo-dev@lists.gentoo.org>; Sat, 26 Mar 2011 10:12:10 +0100 (MET) From: "Andreas K. Huettel" <dilfridge@gentoo.org> To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: rejecting unsigned commits Date: Sat, 26 Mar 2011 10:12:10 +0100 User-Agent: KMail/1.13.6 (Linux/2.6.36-gentoo-r5; KDE/4.6.1; x86_64; ; ) References: <AANLkTi=4o69ytUxAVpy-O31AWQv-5p4bEWD2466NWYGx@mail.gmail.com> <201103252133.27978.dilfridge@gentoo.org> <AANLkTikZoAi5E=WHLhPWPBt+KJfQ3=8+JZEBuxo+gumB@mail.gmail.com> In-Reply-To: <AANLkTikZoAi5E=WHLhPWPBt+KJfQ3=8+JZEBuxo+gumB@mail.gmail.com> 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 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1382429.xyb6lKBbqA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201103261012.17119.dilfridge@gentoo.org> X-Archives-Salt: X-Archives-Hash: dc5a323db84ec1008848fef6fd75419c --nextPart1382429.xyb6lKBbqA Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > first off, fix your e-mail client. this long line crap is ridiculous. :) ever heard of flowed text? absolutely no need to get aggressive... > second, anyone can add/remove e-mail addresses. we arent verifying > e-mail addresses, we're verifying keys. =20 Unfortunately you are misunderstanding the GnuPG trust model here. As a thi= rd=20 party you are not signing someone's key, but someone's userid associated wi= th=20 that key. > the *only* thing that matters > is that the key we have on file (0xabcd) is the one that was used to > sign. That's a policy decision. Basically there are several ways to go by=20 implementing our own trust model. 1) Rely on an existing list of keys somewhere distributed in portage, and=20 automatically trust all keys in that list. VERY BAD, because if someone manipulates the portage tree he/she can=20 manipulate that list as well. I'm pretty confident however you actually mea= nt=20 option 2) or 3): 2) Rely on an existing keyring somewhere distributed in portage; the file (= not=20 the keys themselves) is signed with a master key. Is a very clumsy workaround. Pros: you can exactly decide what keys are used and trusted, without thinki= ng=20 about GnuPG's inner workings. Cons: People tend to modify their keys. Add user ids. Add new subkeys. Expi= re=20 or revoke subkeys. Revoke userids. (My photo in the key is pretty old by no= w.=20 :o) Whenever anything of this happens, the key file changes, needs to be re- signed by infra and re-uploaded. 3) Rely on an existing key list somewhere distributed in portage; the list= =20 file with the key id's (not the keys themselves) is signed with a master ke= y. Is a mediocre and potentially insecure workaround. Pros: you can exactly decide what keys are used and trusted, without thinki= ng=20 about GnuPG's inner workings. A user can edit his key and the key remains=20 trusted. Cons: Mainly that the key id is a pretty short hash afaik.(Any better-infor= med=20 people around?) 4) Rely on an existing list of keys somewhere distributed in portage and=20 possibly somewhere else (keyservers); a key userid is signed with a master= =20 key. Work with GnuPG's well-tested and well-thought-out trust relationships. Back to start, time to re-read the entire thread... :) Am I missing something? =2D-=20 Andreas K. Huettel Gentoo Linux developer=20 dilfridge@gentoo.org http://www.akhuettel.de/ --nextPart1382429.xyb6lKBbqA 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) iEYEABECAAYFAk2NrfEACgkQ3ao2Zwy3NWpRCACeOUkGcpzjUasrFzJxHi8DHMhD pL8AoJ/wlZ0gJ7cy7ZdFcbnosCqTFBNS =/wfq -----END PGP SIGNATURE----- --nextPart1382429.xyb6lKBbqA--