Re: [gentoo-dev] Re: rejecting unsigned commits
On 5/10/11 4:08 AM, Jim Ramsay wrote: - Does this tree signing key have to be DSA? Or is RSA okay too? No idea, I'd probably just try and see if signing works. - If I have a key already, should I generate a new subkey just for manifest signing, make a whole new primary key, or just use the same key I use to sign my emails? See http://archives.gentoo.org/gentoo-dev/msg_bdc24ba33036ef413e620dc94532e080.xml, I think no separate key should be needed. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: rejecting unsigned commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/10/11 02:19, Paweł Hajdan, Jr. wrote: On 5/10/11 4:08 AM, Jim Ramsay wrote: - Does this tree signing key have to be DSA? Or is RSA okay too? No idea, I'd probably just try and see if signing works. - If I have a key already, should I generate a new subkey just for manifest signing, make a whole new primary key, or just use the same key I use to sign my emails? See http://archives.gentoo.org/gentoo-dev/msg_bdc24ba33036ef413e620dc94532e080.xml, I think no separate key should be needed. RSA2048 or so is DSA in my opinion. Just my 2 cents. Regards, - -- Dane Smith (c1pher) Gentoo Linux Developer -- QA / Crypto / Sunrise / x86 RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531op=index -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNyTjnAAoJEEsurZwMLhUxzkoP/21ZvCkM08fkO8Glv1r9jWi2 4+UkYALoBWWvTase5BMxuarliZOiEjxHYStJ9wwY3HAt0GPLpa4HS5SJBgb0VAhd k1khQGLY3mufUpKCmYsad85guAeir5OETemx5cfNCuUUsCcBlFotoo4CQsRTDTmq LAMNPTvXXAdrDzek03q0b6pTiBFEl+5hPQNiyY/VdYOR6/Pmd9qGUS0Cwp1FN9BL oayRh2ngCnu+ebd14cGIGw1OSW/9/7HpnDsg/qDiMFE0ViImWQRCzoYifzUj531K OyG/wA90N9H6fmNXf37v7UzFrZwz42W5rgpbErfAwlcank9/4WyCOHXaMR2KmQE+ 7SjlFy6gy7w1MHNI+d/pzSbpyRdmBdtJ21UD3WxT+kofVoGJ8TRTIHAdrjx+QECC 5JBQDUGzy6b352DHQb2bZcrlESIteeqt6j+XAsMHW/fhaTmXMGq9gDNB+hfdPwYl Uun7ZVr2gUKgpIYXIp+OAvb7VTZlhKQldFtvDuiDYOr/ZdcAk6gGXc252E9N0cHm IQysE1ANAFZ+tDvFcfOt2M/SIxzaReXuwyCgdzfaFzxCP0JMG+KYLTUqRqHi0xLK pNL09gP0DcENRV+9l+x3h1lbZUULoKCnG/jst6n7drW0/m96YJgPvuGodG84hs3Y pQxG4e8XW5Vw6pAlJiir =T+gW -END PGP SIGNATURE-
Re: [gentoo-dev] Re: rejecting unsigned commits
On Tue, May 10, 2011 at 08:19:27AM +0200, Paweł Hajdan, Jr. wrote: On 5/10/11 4:08 AM, Jim Ramsay wrote: - Does this tree signing key have to be DSA? Or is RSA okay too? No idea, I'd probably just try and see if signing works. /me plugs his ears and presses GO... Looks like it works fine! - If I have a key already, should I generate a new subkey just for manifest signing, make a whole new primary key, or just use the same key I use to sign my emails? See http://archives.gentoo.org/gentoo-dev/msg_bdc24ba33036ef413e620dc94532e080.xml, I think no separate key should be needed. You know, I even remember reading this email, but focused more on the SSL Cert recommendation part than immediate answer. Thanks :) -- Jim Ramsay
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 02:30:20PM -0400, Mike Frysinger wrote: for people who dont have a key yet: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=6 I'm pretty new to advanced gpg usage and management, and so had a couple questions not answered by that page: - Does this tree signing key have to be DSA? Or is RSA okay too? - If I have a key already, should I generate a new subkey just for manifest signing, make a whole new primary key, or just use the same key I use to sign my emails? -- Jim Ramsay
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, 25 Mar 2011 10:44:31 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: * the signature proves the key belongs to the e-mail address, nothing else Anyone could generate a signature with one of my @g.o e-mail addresses in it, then pass themselves off as myself, right? If they then trick you into thinking that I sent the mail you received, signed with their key, they're all set. Having the right e-mail address in the key would not improve anything. * the e-mail address is given to the owner of the key during recruitment It's been a while, but I am certain I did not have a @gentoo.org address yet _during_ recruitment, and I was instead asked to provide an address that I _did_ already use. It looks like that still has not changed.[1] Looking at the e-mail from that time, it seems I had been asked to sign my SSH key with it and send it to recruiters@. jer [1] http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2
Re: [gentoo-dev] Re: rejecting unsigned commits
3) 1. Generate said list L from the GPG fields in LDAP (w/ long-form keyids) 2. Clear-sign L, produces L' 3. Include L' in /metadata/ during rsync content build. 3.1. Provide all L' files in a trusted Git repository for historical reference. 4. Tree-sign per GLEP58, such that signed list is included. Pros: - L' is plaintext and works well w/ rsync deltas. Cons: Mainly that the key id is a pretty short hash afaik.(Any better-informed people around?) - Introduces new weak point if attacker can compromise the automated clear-signing service of #2. 4) Rely on an existing list of keys somewhere distributed in portage and possibly somewhere else (keyservers); a key userid is signed with a master key. Work with GnuPG's well-tested and well-thought-out trust relationships. Back to start, time to re-read the entire thread... :) What does this actually add over #3 in terms of security? I don't know. I am basically worried that we are using a well-tested cryptosystem in a hackish way and cannot fully estimate the consequences. (Which is why I hoped someone more knowledgable could comment. I may know approximately how to use gpg, and may have some basic knowledge of the maths behind it, but I have no clue of the data structures and software internals.) I'd say, here the burden of proof is on you. (i.e. that the signed list of long keyids is as secure as a list of signed keys) -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: rejecting unsigned commits
On 3/28/11 2:05 AM, Robin H. Johnson wrote: I see so many bad ideas mentioned in this thread. The suggestions to keep a gpg-agent with a very long passphrase TTL just provides a massive new security hole: === Attacker breaks into developer's system, has access to SSH agent and GPG agent thanks to software like keychain, now can commit as that developer. If a dev machine is compromised, the attacker can install a keylogger and sniff the passphrase. Or he can wait for the dev to enter the password into gpg-agent and then use it. Or pop up a fake passphrase dialog box. There many other things that can happen at that point. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: rejecting unsigned commits
On Sun, Mar 27, 2011 at 10:47 PM, Kumba ku...@gentoo.org wrote: 1. How can I revoke the old key? The revocation cert is probably on the same drive. You can't. You need the private key to generate a revocation certificate. The best you might be able to do is ask keyserver admins to remove it manually, or try to recover the key. Or crack RSA... :) This is one of the reasons PKI is painful. 2. The dev manual states not to create a key with an expiration longer than 6 months. How does this impact items signed already if the key has to be replaced bi-annually? (I suspect I'm not fully grasping something here w/r to GPG). When gpg verifies signatures it takes into account the date the signature was performed. So, after this date the key is not valid for new signatures. Expiration dates are more about receiving encrypted data than sending it. Basically it tells people who have your public key to please be nice and not use this key after this date, that way I don't need to keep a copy of old keys until the end of time just in case. In your case, when your old key expires you will no longer need to worry about getting an encrypted email you can't read. They provide no security for stolen keys, since the date can be changed if you have access to the private key. This is in contrast to SSL certificates, where the CA key would be needed to do this. With SSL the expiry is more about the CA than the key itself. The only security mechanism for stolen certs is revocation. 3. If I'm going to start using GPG, I might as well use it for a few things. Anyone got pointers for cross-platform use, i.e., Thunderbird on Windows? Enigmail. Haven't actually used it on windows but it is pretty transparent and I believe it supports windows. No graceful solution to keyring management that I know of, except that the same files should work on both platforms, and either platform can merge two keyring files which should make syncs easy (you're generally only adding to them all the time). Rich
Re: [gentoo-dev] Re: rejecting unsigned commits
On 2011-03-28 2:54 PM, Rich Freeman wrote: 3. If I'm going to start using GPG, I might as well use it for a few things. Anyone got pointers for cross-platform use, i.e., Thunderbird on Windows? Enigmail. Haven't actually used it on windows but it is pretty transparent and I believe it supports windows. Aye, enigmail and thunderbird works on windows. And gpg4win if you have to use outlook and/or claws. No graceful solution to keyring management that I know of WinPT is our preferred solution on windows. -- Eray Aslan Developer, Gentoo Linux eras at gentoo.org
Re: [gentoo-dev] Re: rejecting unsigned commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/27/2011 08:13 PM, Robin H. Johnson wrote: On Sat, Mar 26, 2011 at 10:12:10AM +0100, Andreas K. Huettel wrote: 3) Rely on an existing key list somewhere distributed in portage; the list file with the key id's (not the keys themselves) is signed with a master key. Is a mediocre and potentially insecure workaround. Pros: you can exactly decide what keys are used and trusted, without thinking about GnuPG's inner workings. A user can edit his key and the key remains trusted. Cons: Mainly that the key id is a pretty short hash afaik.(Any better-informed people around?) 1. Generate said list L from the GPG fields in LDAP (w/ long-form keyids) 2. Clear-sign L, produces L' 3. Include L' in /metadata/ during rsync content build. 3.1. Provide all L' files in a trusted Git repository for historical reference. 4. Tree-sign per GLEP58, such that signed list is included. Pros: - L' is plaintext and works well w/ rsync deltas. Security weakpoints: - Introduces new weak point if attacker can compromise the automated clear-signing service of #2. 4) Rely on an existing list of keys somewhere distributed in portage and possibly somewhere else (keyservers); a key userid is signed with a master key. Work with GnuPG's well-tested and well-thought-out trust relationships. Back to start, time to re-read the entire thread... :) What does this actually add over #3 in terms of security? This is an extremely non-trivial question. You're talking about signing each individual key's fingerprint vs generating a list of key fingerprints (hashes of the key), concatenating them all, hashing THAT, and then signing that hash. - From a cryptologic point of view, I would be *extremely* impressed with anyone that can find a proof of security that shows that those two are equivalent. Simple(ish) example. By creating a list you're introducing a lot of data that is then getting hashed. Now, from a cryptologic point of view, I would *not* attack the signature per se, but rather the underlying hash of the list. By providing a large file with lots of data, there are attacks against (some) has functions that can make use of this (Small changes in the file that will result in the same hash with probability greater than normal). (Anyone know off the cuff what hash is actually used?) Now, the other method would require having to single out each hash on it's own, and the underlying key that it hashed. That data is harder to deal with because you have to manipulate one key into another *valid* key(a difficult task to have it still be valid) and have it come out with the same hash. Whereas with the file, who cares if they invalidate another key, as long as they can get their hash into the file and have the hash for the sig come out the same. Point being, what it adds / subtracts is not a simple question. Crypto is a funny beast, and is best not trifled with unless you understand the underlying math / the current attacks etc (And even then, don't do it =P). Do I think that using #4 gives us a huge difference over #3, even with my years of study on this topic I would not even begin to try to answer that. Chances are the difference is negligible for our *needs* (see below), but I don't think it's negligible in the true sense of security. Having said that we aren't exactly talking about securing the end all be all. We just want to be able to verify with a reasonable degree of certainty that the tree is in a good state and that it wasn't tampered with. Do we really need the end all be all, I somehow doubt it. - -- Dane Smith (c1pher) Gentoo Linux Developer -- QA / Crypto / Sunrise / x86 RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531op=index -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNkLnkAAoJEEsurZwMLhUxV64P/1AbiEkcbouFd/XZ50aq/BsC LRjlUC5GbCpBL1MBTigP1OWO0HT8JvBEKJPAbwChr+KSQqtk3/HOcaoRTlJDz3hf iG7NrKkh4VECwErshFpzS1/D0D7M2qFXABat7DE/lPmFrIpI96XSd+ZAnjLMtM0g RoFOAyJ3s3CEIKeG3n448TQagpHkAGinzgkmtA8NZRUf/ziukA7Gk7lQGC+e9YIE MViWW4bBB1PQq4XL5in58JH2ohQBx49+RgeovdREnTWFJlDsHbxIZN3JTV8EHq7a 8xpni/uPLCbW3XGS2G3x/L7f8yPJOqEyTPROU3s+YGDtZkDYwDI1bn+k2Fnu+3a7 kkFyp4aRrajiFE4WK20iBnnPJn1knfR47O6UEP4aZu/GCC3s/3fJP5pVNlnla7mU 5RXJ1j6Tj3MQoCBdbGypEaVYJf1ZiJGdpUYOHpi4XL2R3mh8XsmnEF53pdp7GOk/ wHfuKvvZ5uKtYawj8QhVB8+Y97kTNYc7t7OIShpAZb0SoyUN+ZGoal4pDASkSM15 uATdmilb7z5JIEKiQ0lLwjdLjJJq5imgpB4YuQBqiF3sKmH8N9Qf5+kCRxvSE09y lq1hWqppGX+H4CvA5FPRkB7/Qvg2prmwfdIqDlGWfMlR2KLsFoIzRyjKnL1xSCgn eX/hTD9umMkzOho7l1eL =h4nm -END PGP SIGNATURE-
Re: [gentoo-dev] Re: rejecting unsigned commits
On 03/27/2011 22:47, Kumba wrote: Rather than mounting an expedition to find it, it's probably easier for me to generate a new key, but this raises a few questions, because I'm a complete idiot when it comes to GPG/PGP stuff: This is all fixed. My new key is published, but the old one will remain on the key servers until I can hunt down the drive w/ the old revocation cert. Will have to play with manifest signing next time I update mips-sources... -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Re: rejecting unsigned commits
On Sat, Mar 26, 2011 at 10:12:10AM +0100, Andreas K. Huettel wrote: 3) Rely on an existing key list somewhere distributed in portage; the list ... Cons: Mainly that the key id is a pretty short hash afaik.(Any better-informed people around?) You can use the long-format key IDs if you want. 0xB27B944E34884E85 is my long-form key. Am I missing something? In my tree-signing GLEPs, I explicitly pointed out that the developer signing of content only had real value for the developer-CVS part of the chain. Specifically, that while building the rsync tree for distribution, we can verify that the content we are preparing was indeed from a developer. Please re-read GLEP57. Everything in this thread been attempting to apply solutions to 'Process #1' (developer-infrastructure) to provide direct security for the end user after 'Process #2' (infrastructure-mirrors-users). What can we be certain of? 1. Developers should be signing manifests. 2. Infrastructure should be verifying those commits before pushing out to rsync. 3. Regardless of their choice of rsync or websync, users need to be able to verify that the tree that left Infrastructure was not modified in transit. RegI see so many bad ideas mentioned in this thread. The suggestions to keep a gpg-agent with a very long passphrase TTL just provides a massive new security hole: === Attacker breaks into developer's system, has access to SSH agent and GPG agent thanks to software like keychain, now can commit as that developer. === Is this the easiest attack? No, certainly not, looking at mirrors mirror, potentially a running deliberate selective malicious mirror would be much easier. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpDvfvXctmiO.pgp Description: PGP signature
Re: [gentoo-dev] Re: rejecting unsigned commits
On Sat, Mar 26, 2011 at 10:12:10AM +0100, Andreas K. Huettel wrote: 3) Rely on an existing key list somewhere distributed in portage; the list file with the key id's (not the keys themselves) is signed with a master key. Is a mediocre and potentially insecure workaround. Pros: you can exactly decide what keys are used and trusted, without thinking about GnuPG's inner workings. A user can edit his key and the key remains trusted. Cons: Mainly that the key id is a pretty short hash afaik.(Any better-informed people around?) 1. Generate said list L from the GPG fields in LDAP (w/ long-form keyids) 2. Clear-sign L, produces L' 3. Include L' in /metadata/ during rsync content build. 3.1. Provide all L' files in a trusted Git repository for historical reference. 4. Tree-sign per GLEP58, such that signed list is included. Pros: - L' is plaintext and works well w/ rsync deltas. Security weakpoints: - Introduces new weak point if attacker can compromise the automated clear-signing service of #2. 4) Rely on an existing list of keys somewhere distributed in portage and possibly somewhere else (keyservers); a key userid is signed with a master key. Work with GnuPG's well-tested and well-thought-out trust relationships. Back to start, time to re-read the entire thread... :) What does this actually add over #3 in terms of security? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpwQC5IuPHgi.pgp Description: PGP signature
Re: [gentoo-dev] Re: rejecting unsigned commits
On 03/25/2011 14:30, Mike Frysinger wrote: for people who dont have a key yet: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=6 for people interested, bugs to get repoman extended to make the gpg process smoother: http://bugs.gentoo.org/360459 http://bugs.gentoo.org/360461 -mike So I'm one of those that became a dev before GPG keys were required (I think). at some point, though, I created one on an old machine I had, which was my primary dev machine at the time. But the machine died, and I never got the key off (I never used it). The drive is still good, but it's lost in a pile of boxes somewhere. Rather than mounting an expedition to find it, it's probably easier for me to generate a new key, but this raises a few questions, because I'm a complete idiot when it comes to GPG/PGP stuff: 1. How can I revoke the old key? The revocation cert is probably on the same drive. 2. The dev manual states not to create a key with an expiration longer than 6 months. How does this impact items signed already if the key has to be replaced bi-annually? (I suspect I'm not fully grasping something here w/r to GPG). 3. If I'm going to start using GPG, I might as well use it for a few things. Anyone got pointers for cross-platform use, i.e., Thunderbird on Windows? -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Re: rejecting unsigned commits
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. Unfortunately you are misunderstanding the GnuPG trust model here. As a third party you are not signing someone's key, but someone's userid associated with 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 implementing our own trust model. 1) Rely on an existing list of keys somewhere distributed in portage, and automatically trust all keys in that list. VERY BAD, because if someone manipulates the portage tree he/she can manipulate that list as well. I'm pretty confident however you actually meant option 2) or 3): 2) Rely on an existing keyring somewhere distributed in portage; the file (not 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 thinking about GnuPG's inner workings. Cons: People tend to modify their keys. Add user ids. Add new subkeys. Expire or revoke subkeys. Revoke userids. (My photo in the key is pretty old by now. :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 file with the key id's (not the keys themselves) is signed with a master key. Is a mediocre and potentially insecure workaround. Pros: you can exactly decide what keys are used and trusted, without thinking about GnuPG's inner workings. A user can edit his key and the key remains trusted. Cons: Mainly that the key id is a pretty short hash afaik.(Any better-informed people around?) 4) Rely on an existing list of keys somewhere distributed in portage and possibly somewhere else (keyservers); a key userid is signed with a master 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? -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: rejecting unsigned commits
* Mike Frysinger vap...@gentoo.org: On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote: [Manifest signing] Does that get us any closer to GLEPs 57, 58, 59 (or generally approaching the tree-signing/verifying group of problems)? yes I think, it's a no. The MetaManifest GLEP relies on a signed top-level MetaManifest which hashes all sub Manifests, whether they are signed or not doesn't matter. I don't see a major advantage to signed portage snapshots we already offer today. Do you want to reject signed commits if - keys are not publicly available [1] - signatures are from expired keys [2] - keys are revoked [3] - keys are not listed in userinfo.xml (current or former devs) [4] [1] https://bugs.gentoo.org/205405 [2] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/signatures_by_expired_keys.txt [3] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/signatures_by_revoked_keys.txt [4] http://dev.gentoo.org/~tove/stats/gentoo-x86/Manifest/keys_in_use.txt
Re: [gentoo-dev] Re: rejecting unsigned commits
On 03/25/11 15:15, Torsten Veller wrote: * Mike Frysinger vap...@gentoo.org: On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote: [Manifest signing] Does that get us any closer to GLEPs 57, 58, 59 (or generally approaching the tree-signing/verifying group of problems)? yes I think, it's a no. The MetaManifest GLEP relies on a signed top-level MetaManifest which hashes all sub Manifests, whether they are signed or not doesn't matter. I'd say that those are two independent issues. But by starting to figure out how to force signed commits for everyone we at least get the infrastructure done. As long as we have no strict guidelines I don't see any advantage of using signed commits, so I've never used them. Getting a coherent policy for that sounds like a really good idea (key length, expiry time, availability on keyservers etc.) I don't see a major advantage to signed portage snapshots we already offer today. Do you want to reject signed commits if - keys are not publicly available [1] - signatures are from expired keys [2] - keys are revoked [3] - keys are not listed in userinfo.xml (current or former devs) [4] Yes, yes, yes, and yes :) But since we don't have policies in place yet it's a bit of a mess right now. So. What parameters do we need to agree on? And what's a realistic timeframe *if* we decide to go ahead with it? Waiting for good answers :) Patrick -- Patrick Lauer http://service.gentooexperimental.org Gentoo Council Member and Evangelist Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
Re: [gentoo-dev] Re: rejecting unsigned commits
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 possible.) No if the signature was made while the key was valid. (Otherwise our whole 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. However, for the former devs we might need an extra list to prevent expiration on retirement, and treat the keys as if they expired on 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 address. E.g. dilfri...@gentoo.org Very important and easily implemented. * The userid should have some specific default string in its comment field, like Gentoo manifest signing key. Not so important but also easily implemented. * The key should be signed by some central instance for automated validity check. Here things get hairy. How about having recruiter/infra team sign a dev's key 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 yourself into the foot backwards through the eye? Cheers, A -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: rejecting unsigned commits
Andreas K. Huettel dixit (2011-03-25, 09:53): 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 possible.) No if the signature was made while the key was valid. (Otherwise our whole 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. However, for the former devs we might need an extra list to prevent expiration on retirement, and treat the keys as if they expired on 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 address. E.g. dilfri...@gentoo.org Very important and easily implemented. * The userid should have some specific default string in its comment field, like Gentoo manifest signing key. Not so important but also easily implemented. * The key should be signed by some central instance for automated validity check. Here things get hairy. How about having recruiter/infra team sign a dev's key on completion of the recruitment process? Just a first thought... I think this is an important requirement however it's quite difficult to conduct reliably. A normal keysigning process usually requires knowing one personally (and perhaps verifying fingerprints over a phone with voice verification), seeing one's ID personally and the like. This is probably unfeasible in the Gentoo development environment (I'm not a dev, though, so I'm just guessing). As a weaker but possibly useful workaround Gentoo Infra could just publish a signed list of trusted developer keys for any given moment. * 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 yourself into the foot backwards through the eye? Revoking a signature on a key is possible (unless a key has been nrsigned) and makes sense (assuming those who verify update all relevant keys). -- [a] pgpZbkdFEvCEY.pgp Description: PGP signature
Re: [gentoo-dev] Re: rejecting unsigned commits
Torsten Veller dixit (2011-03-25, 08:15): * Mike Frysinger vap...@gentoo.org: On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote: [Manifest signing] Does that get us any closer to GLEPs 57, 58, 59 (or generally approaching the tree-signing/verifying group of problems)? yes I think, it's a no. The MetaManifest GLEP relies on a signed top-level MetaManifest which hashes all sub Manifests, whether they are signed or not doesn't matter. I don't see a major advantage to signed portage snapshots we already offer today. It's just that for everyday use we (perspective of users, possibly only me) would like to have the ability of easy and automated verifying of Manifest GPG signatures whether we (r)sync, webrsync or use a manually downloaded snapshot, with same level of assurance as in other major distros (Debian, RH). Regards, -- [a]
Re: [gentoo-dev] Re: rejecting unsigned commits
* The key should be signed by some central instance for automated validity check. Here things get hairy. How about having recruiter/infra team sign a dev's key on completion of the recruitment process? Just a first thought... I think this is an important requirement however it's quite difficult to conduct reliably. A normal keysigning process usually requires knowing one personally (and perhaps verifying fingerprints over a phone with voice verification), seeing one's ID personally and the like. This is probably unfeasible in the Gentoo development environment (I'm not a dev, though, so I'm just guessing). Well, as long as the signed UID is the specific Gentoo address UID, this should be no problem, since... * the signature proves the key belongs to the e-mail address, nothing else * the e-mail address is given to the owner of the key during recruitment Meaning nobody is certifying something that he/she does not know already by definition. Please point out any thinkos... :) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: rejecting unsigned commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/25/2011 05:44 AM, Andreas K. Huettel wrote: * The key should be signed by some central instance for automated validity check. Here things get hairy. How about having recruiter/infra team sign a dev's key on completion of the recruitment process? Just a first thought... I think this is an important requirement however it's quite difficult to conduct reliably. A normal keysigning process usually requires knowing one personally (and perhaps verifying fingerprints over a phone with voice verification), seeing one's ID personally and the like. This is probably unfeasible in the Gentoo development environment (I'm not a dev, though, so I'm just guessing). Well, as long as the signed UID is the specific Gentoo address UID, this should be no problem, since... * the signature proves the key belongs to the e-mail address, nothing else * the e-mail address is given to the owner of the key during recruitment Meaning nobody is certifying something that he/she does not know already by definition. Please point out any thinkos... :) This is 100% correct. We are not attempting to verify identity. Whether or not my name is Dane Smith is a moot point. All that matters is that I am the person that the Gentoo recruiters granted access to. I cannot stress how important some of this is. It's bad if a binary distro doesn't sign their code, but in some ways it's even worse for us. An ebuild can do most anything. If someone were to want to insert some nastiness into say, openssl, all they have to do is hijack an rsync mirror, insert their patch, change the ebuild a smidge, and run and hide. And no one would be any the wiser. The only difference is that unlike a binary distro where a user can't verify anything (easily), at least one of ours can always look at the ebuilds / patches. (Not to mention they could also hack their nastiness into the openssl tarball, change the manifest, and then run and hide. Same effect, no notice at the ebuild level.) For those who got bored at line two it all comes down to: Sign. Your. STUFF! Your friendly neighborhood paranoid, - -- Dane Smith (c1pher) Gentoo Linux Developer -- QA / Crypto / Sunrise / x86 RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531op=index -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNjIAtAAoJEEsurZwMLhUxVFAP/3aXbJb+00wM95Dht/aBT31S vjsjODbx7/9IL5nxdVumDH6+M21pfa7e0xx1aFsUNvjJNl1jSfH44nsvvjRSkGKq b8bliwpG++wnQ18Gll1J48XTawLCPKh5HKCQWoRmQPwk7oEkVxXmph/V5/S8PdvL Y9HM7niA6TeIKtdDjtd/AqgdIizDlrU8a4ovdxrt4MdhPoBSs4CT5BUQszgOEWah LW/nt/Ir3bL2aML60QBmoxapbCBYSrpn0cqBoBCvOhgTzWWOpAamBV21HxBhiAnE EzAXYAm8IJH4HWwQp4ar0e/TCo7/mty3mx/lspAFuX4fOXwVgfCS53wtpT7nKvoA Homy0Q1ZnVMU/bXP5tdvszzPcfRoqfvjO4qU8MlqvlHLKf/RF1Om3kJRYONKTYxo EDtrT093kRNwI2s3RrrWyJ14Kj6QsKAylsO9KbD5+h+xH/LG1+uWpxxtm0S88A// qSkU/kP1TRJW7+PxYiodBu5rlqcW+v6JK+jXwTecz96QVrYvsBq6QTBvHODpsxlI CFBePa23LEbPqq+vnQSrSLXrbeqV9nw4vgvMiU9PHbiWuPDks37xh4mtQY0u/5C9 R4U7VG1sQ0yZQSH0I9HP8v6ZNz99xdyH+VDDJzIvBGdpif1CPyGA4DNmhfvmzpaC 0zqc8QcUe5rJRV5N2zmb =T/Hi -END PGP SIGNATURE-
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, 25 Mar 2011 09:53:01 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: Of course now we can add additional requirements: * The key must have an userid that refers to an official Gentoo e-mail address. E.g. dilfri...@gentoo.org I think this is pretty useless assuming we're already wanting to limit the amount of keys trusted to a specific list. * The userid should have some specific default string in its comment field, like Gentoo manifest signing key. What's the point of this? I don't see a reason to enforce a dev to have a dedicated Manifest signing key, and even more I don't see a reason to add such comments to normal keys. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, 25 Mar 2011 08:15:32 +0100 Torsten Veller ml...@veller.net wrote: Do you want to reject signed commits if - keys are not publicly available [1] We'll need to define what does 'public availability' exactly mean? Does that mean a specific keyserver? - keys are revoked [3] How about manifests signed before the key was revoked? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: rejecting unsigned commits
* The key must have an userid that refers to an official Gentoo e-mail address. E.g. dilfri...@gentoo.org I think this is pretty useless assuming we're already wanting to limit the amount of keys trusted to a specific list. See the remark in a separate sub-thread about signing... Deciding key validity based on signatures is a lot better than based on a central list. Otherwise we are just duplicating existing infrastructure. * The userid should have some specific default string in its comment field, like Gentoo manifest signing key. What's the point of this? I don't see a reason to enforce a dev to have a dedicated Manifest signing key, and even more I don't see a reason to add such comments to normal keys. Well it's probably not necessary. It might simplify identification of the UID that determines key validity though. -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: rejecting unsigned commits
Do you want to reject signed commits if - keys are not publicly available [1] We'll need to define what does 'public availability' exactly mean? Does that mean a specific keyserver? Good point. Although most keyservers synchronize each other, it might make sense to define an additional location such as e.g. a keyring for download on www.gentoo.org. - keys are revoked [3] How about manifests signed before the key was revoked? And about keys being revoked by a revocation certificate that was generated long time ago just in case (as even our docs recommend)... Yes I know this is a mess. -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 3:15 AM, Torsten Veller ml-en@veller.wrote: * Mike Frysinger vap...@gentoo.org: On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote: [Manifest signing] Does that get us any closer to GLEPs 57, 58, 59 (or generally approaching the tree-signing/verifying group of problems)? yes I think, it's a no. The MetaManifest GLEP relies on a signed top-level MetaManifest which hashes all sub Manifests, whether they are signed or not doesn't matter. that's *one* of the three gleps Do you want to reject signed commits if - keys are not publicly available [1] no. e-mail warnings will be issued so that the dev can upload it after the fact. - signatures are from expired keys [2] not generally an issue since gpg itself will not allow it, but i guess we can be paranoid about it on the server to avoid people locally turning back their clocks after having snipped someones expired key. we might want to add an automatic e-mail warning to the developer when their key is about to expire (like 1 week). - keys are revoked [3] yes - keys are not listed in userinfo.xml (current or former devs) [4] no. you can sign a key with your personal key and that's good enough. -mike
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 10:33 AM, Michał Górny wrote: On Fri, 25 Mar 2011 08:15:32 +0100 Torsten Veller wrote: - keys are revoked [3] How about manifests signed before the key was revoked? you cant do this at commit time (computers cant predict the future), so it has no bearing on the original idea people who need to revoke their key are responsible for either notifying the Gentoo community of the issue and verifying that all the commits in the tree before their revocation were actually made by them -mike
[gentoo-dev] Re: rejecting unsigned commits
for people who dont have a key yet: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=6 for people interested, bugs to get repoman extended to make the gpg process smoother: http://bugs.gentoo.org/360459 http://bugs.gentoo.org/360461 -mike
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 2:26 PM, Mike Frysinger wrote: we might want to add an automatic e-mail warning to the developer when their key is about to expire (like 1 week). on 2nd thought, no need. we'll let repoman handle it locally. -mike
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 2:26 PM, Mike Frysinger vap...@gentoo.org wrote: - keys are revoked [3] yes To facilitate this, should we pick a preferred keyserver or two? Devs of course are welcome to use others also, but if we're going to check for revocations, we should specify where devs should upload them to in order to make sure they hit the tree/etc. The preference need not be strictly applied, but even though those keyservers are supposed to talk to each other I've found that I get fairly different results if I refresh against various ones. Rich
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 2:33 PM, Rich Freeman wrote: On Fri, Mar 25, 2011 at 2:26 PM, Mike Frysinger wrote: - keys are revoked [3] yes To facilitate this, should we pick a preferred keyserver or two? Devs of course are welcome to use others also, but if we're going to check for revocations, we should specify where devs should upload them to in order to make sure they hit the tree/etc. The preference need not be strictly applied, but even though those keyservers are supposed to talk to each other I've found that I get fairly different results if I refresh against various ones. in practice, i think we've been requiring hkp://subkeys.pgp.net -mike
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 4:53 AM, Andreas K. Huettel wrote: Of course now we can add additional requirements: * The key must have an userid that refers to an official Gentoo e-mail address. E.g. dilfri...@gentoo.org no. there's no reason for this requirement, and it prevents proxy maintenance long term. e-mail addresses do not verify identity, verifying identify verifies identity. this is the point of the web of trust. -mike
Re: [gentoo-dev] Re: rejecting unsigned commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/25/2011 02:46 PM, Mike Frysinger wrote: On Fri, Mar 25, 2011 at 4:53 AM, Andreas K. Huettel wrote: Of course now we can add additional requirements: * The key must have an userid that refers to an official Gentoo e-mail address. E.g. dilfri...@gentoo.org no. there's no reason for this requirement, and it prevents proxy maintenance long term. e-mail addresses do not verify identity, verifying identify verifies identity. this is the point of the web of trust. -mike We are somewhat limited in the amount that we can verify identity. Sure you can get a decent web of trust from signing the keys of people you've met at conferences, however, there will be people outside of that web. What we need to verify is rather that the person who made the commit is someone who is authorized to make the commit and that it was in no way tampered with. - -- Dane Smith (c1pher) Gentoo Linux Developer -- QA / Crypto / Sunrise / x86 RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531op=index -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNjOWQAAoJEEsurZwMLhUxKnMQAKKbtRbdIDK++MpSWEJKg4Un gBhlPRtZ4CxoNGh5DRcgHD4k6eq8a7fE9MjPuge9/prDfLjmFW7nr0FJ9olZzXoG F5qvsCerpPNN2dw6ccCotP3UQCPyjADdZ4mRvmcMdlWdzluq3rD631mzEw8+m4cM EJz1DF2q9Oi2Zca8wxlPXf3+11NqHt2bnMWQhkoWFDtAVLD+rPoIsZsV6mRz+ip7 uWX8TiMoZCJgRAA0NqCVph4B3kGzn+xcwHuvlcoK87j7ShZKJD4sh0W6GOoewq9A Ei+Idsgx+POYg7t8q5khD2tJQRBBSEnBqARgnMJnun6WA4w+Wls7Hw9nidttBXuY isbdOUy4t7G2W2l7juG83RuGxLJ4UQMKcD4dWMKcpgHmU5ZXl6W2q+lgMIf5oz6x SFk6UGxwf8QbJVL65tKQRytZfdJS1zGvtfdofTHLIYMofhobZH9TqqhZLr7Nf0l3 wPukQA7I212bfCjP3VNApVdAtAIJk353hWloGk0xOQBzMqHraIX7hnPxdHg+qVOo MjCTt9JnlynkwKqPUdrtyjTH3vXpHuyBqy4wSwpfoaJDetDAtsHOcoZxK9LR4xtl FQ8AdYADSDmMPSsbd1SrxLA4XM7BHJx1LolxzlGz4s08SnCaIHoVD9EChRr3IkL2 OFwD0Su4CZ9mQBjsYy8K =kuoA -END PGP SIGNATURE-
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 02:36:14PM -0400, Mike Frysinger wrote: To facilitate this, should we pick a preferred keyserver or two? Devs of course are welcome to use others also, but if we're going to check for revocations, we should specify where devs should upload them to in order to make sure they hit the tree/etc. The preference need not be strictly applied, but even though those keyservers are supposed to talk to each other I've found that I get fairly different results if I refresh against various ones. in practice, i think we've been requiring hkp://subkeys.pgp.net Subkeys.pgp.net is a rotation that's been a bit buggy of late. Of the 5 IPs in it right now: - 2 respond to pings, but not connections - 1 totally unreachable - 2 that work, but have slightly different versions of my key. The SKS rotation seems to be much better, and kingtaco was looking at running an additional SKS instance within Gentoo as our offical key point (also useful for speeding up fetching keys in verification). x-hkp://pool.sks-keyservers.net http://sks-keyservers.net/status/ http://sks-keyservers.net/overview-of-pools.php -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpxGxlPytMWo.pgp Description: PGP signature
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 2:57 PM, Dane Smith wrote: On 03/25/2011 02:46 PM, Mike Frysinger wrote: On Fri, Mar 25, 2011 at 4:53 AM, Andreas K. Huettel wrote: Of course now we can add additional requirements: * The key must have an userid that refers to an official Gentoo e-mail address. E.g. dilfri...@gentoo.org no. there's no reason for this requirement, and it prevents proxy maintenance long term. e-mail addresses do not verify identity, verifying identify verifies identity. this is the point of the web of trust. We are somewhat limited in the amount that we can verify identity. Sure you can get a decent web of trust from signing the keys of people you've met at conferences, however, there will be people outside of that web. creating one tree key which signs all developer keys listed in LDAP is trivial to do What we need to verify is rather that the person who made the commit is someone who is authorized to make the commit and that it was in no way tampered with. you're validating only that the machine with access to the private keys pushed up the commit. hopefully the only person with said machine is the one we recruited. -mike
Re: [gentoo-dev] Re: rejecting unsigned commits
* The key must have an userid that refers to an official Gentoo e-mail address. E.g. dilfri...@gentoo.org no. there's no reason for this requirement, and it prevents proxy maintenance long term. e-mail addresses do not verify identity, verifying identify verifies identity. this is the point of the web of trust. So what sort of identity do you want to verify? Seriously, at the moment when I got my commit bit, noone from Gentoo had ever met me in person, and for sure noone had ever had a look at my passport or any similar legal document. The only established connection was my preexisting gpg key, which was then coupled to my gentoo account. As for proxy maintenance, isn't the whole point of that that the proxied maintainers are not devs and do not have (commit access | a gentoo.org user id)? I do not understand how this would prevent proxy maintenance. Now, e.g. overlay access is a different matter. But first things first. -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: rejecting unsigned commits
Do you want to reject signed commits if - keys are not publicly available [1] no. e-mail warnings will be issued so that the dev can upload it after the fact. Why? I'm pretty sure someone will forget. (Or try to trick the system.) - keys are revoked [3] yes Only if the signature was made after the date/time of the revocation. - keys are not listed in userinfo.xml (current or former devs) [4] no. you can sign a key with your personal key and that's good enough. Heh. Yes, if there is a validity that can be checked in an automated way. Which means a signature on the userid. A chain of trust can of course be implemented in many ways, but requiring the user to download the entire strong set is not an option. :o) The @gentoo.org email addresses are advantageous because they provide a pre-existing identification. Which is as strong as we will ever get with this mechanism (I think). -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: rejecting unsigned commits
The SKS rotation seems to be much better, and kingtaco was looking at running an additional SKS instance within Gentoo as our offical key point (also useful for speeding up fetching keys in verification). Good idea. -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 3:50 PM, Andreas K. Huettel wrote: * The key must have an userid that refers to an official Gentoo e-mail address. E.g. dilfri...@gentoo.org no. there's no reason for this requirement, and it prevents proxy maintenance long term. e-mail addresses do not verify identity, verifying identify verifies identity. this is the point of the web of trust. So what sort of identity do you want to verify? Seriously, at the moment when I got my commit bit, noone from Gentoo had ever met me in person, and for sure noone had ever had a look at my passport or any similar legal document. The only established connection was my preexisting gpg key, which was then coupled to my gentoo account. and no where do we require you to generate a gpg key bound to the Gentoo e-mail address. we require you to provide a gpg key only. like you said *right here*, we have 0 information to identify you, and using a Gentoo e-mail address adds *nothing* to that. so why add a completely useless requirement ? As for proxy maintenance, isn't the whole point of that that the proxied maintainers are not devs and do not have (commit access | a gentoo.org user id)? I do not understand how this would prevent proxy maintenance. uhh, you already pointed out how -- git. if i pull updates from a proxy maintainer, it's going to have his signing. -mike
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 3:57 PM, Andreas K. Huettel wrote: The @gentoo.org email addresses are advantageous because they provide a pre-existing identification. Which is as strong as we will ever get with this mechanism (I think). no, it really doesnt. when we make someone a dev, they give us a ssh key and a gpg key. that is all we need. the gpg key being bound to a @gentoo.org e-mail address is completely meaningless. -mike
Re: [gentoo-dev] Re: rejecting unsigned commits
So what sort of identity do you want to verify? Seriously, at the moment when I got my commit bit, noone from Gentoo had ever met me in person, and for sure noone had ever had a look at my passport or any similar legal document. The only established connection was my preexisting gpg key, which was then coupled to my gentoo account. and no where do we require you to generate a gpg key bound to the Gentoo e-mail address. we require you to provide a gpg key only. like you said *right here*, we have 0 information to identify you, and using a Gentoo e-mail address adds *nothing* to that. so why add a completely useless requirement ? Because, pointing out the obvious, the key can contain all sorts of random true or false information. I could have an user id saying Barack Obama presid...@whitehouse.gov. To be able to do key validation based on gpg's mechanisms, an userid needs to be signed. As e.g. Scarabeus and Wired can confirm, I'm definitely not Barack Obama, but for less obvious cases the validity of the provided identity may be unclear. Now, if I add an userid dilfri...@gentoo.org to my key, this userid does not contain any information that is not already verified and in the Gentoo infra data. So, this one userid could be signed immediately by a central instance without any further fuss. It's imho not a hard requirement, but it considerably eases administration. So why not require it for devs? As for proxy maintenance, isn't the whole point of that that the proxied maintainers are not devs and do not have (commit access | a gentoo.org user id)? I do not understand how this would prevent proxy maintenance. uhh, you already pointed out how -- git. if i pull updates from a proxy maintainer, it's going to have his signing. Point taken... -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 4:33 PM, Andreas K. Huettel wrote: and no where do we require you to generate a gpg key bound to the Gentoo e-mail address. we require you to provide a gpg key only. like you said *right here*, we have 0 information to identify you, and using a Gentoo e-mail address adds *nothing* to that. so why add a completely useless requirement ? Because, pointing out the obvious, the key can contain all sorts of random true or false information. I could have an user id saying Barack Obama presid...@whitehouse.gov. To be able to do key validation based on gpg's mechanisms, an userid needs to be signed. As e.g. Scarabeus and Wired can confirm, I'm definitely not Barack Obama, but for less obvious cases the validity of the provided identity may be unclear. Now, if I add an userid dilfri...@gentoo.org to my key, this userid does not contain any information that is not already verified and in the Gentoo infra data. So, this one userid could be signed immediately by a central instance without any further fuss. first off, fix your e-mail client. this long line crap is ridiculous. second, anyone can add/remove e-mail addresses. we arent verifying e-mail addresses, we're verifying keys. the *only* thing that matters is that the key we have on file (0xabcd) is the one that was used to sign. It's imho not a hard requirement, but it considerably eases administration. So why not require it for devs? it makes 0 difference to administration -mike
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 7:28 PM, Mike Frysinger vap...@gentoo.org wrote: On Fri, Mar 25, 2011 at 2:57 PM, Dane Smith wrote: On 03/25/2011 02:46 PM, Mike Frysinger wrote: On Fri, Mar 25, 2011 at 4:53 AM, Andreas K. Huettel wrote: Of course now we can add additional requirements: * The key must have an userid that refers to an official Gentoo e-mail address. E.g. dilfri...@gentoo.org no. there's no reason for this requirement, and it prevents proxy maintenance long term. e-mail addresses do not verify identity, verifying identify verifies identity. this is the point of the web of trust. We are somewhat limited in the amount that we can verify identity. Sure you can get a decent web of trust from signing the keys of people you've met at conferences, however, there will be people outside of that web. creating one tree key which signs all developer keys listed in LDAP is trivial to do What we need to verify is rather that the person who made the commit is someone who is authorized to make the commit and that it was in no way tampered with. you're validating only that the machine with access to the private keys pushed up the commit. hopefully the only person with said machine is the one we recruited. -mike Coming back around to the earlier discussion of Alice who has her key signed by robbat2 (because he loves keysigning parties) and then Alice breaks into cvs.gentoo.org and commits evil code into the tree. If we cannot stop this attack because we are relying on a chain of trust (and Alice is in the chain) can we at least detect the attack? As it appears to me; I am much more likely to somehow manipulate the chain in trust in an incorrect way (such as at a keysigning hibjib) as opposed to adding some random strangers key to a master list on dev.gentoo.org or in LDAP. The former action is essentially an innocent act with non-obvious (to me) repercussions and the latter is an act with really only one intent. I don't care about GPG at all. I hate it. I don't want to know how it works and I don't want developers who are in the same boat as me to fuck it up because they don't know what they are doing. I don't have commit-bit to gentoo-x86 so I don't have a big stake in this ;)
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 10:38 PM, Alec Warner wrote: Coming back around to the earlier discussion of Alice who has her key signed by robbat2 (because he loves keysigning parties) and then Alice breaks into cvs.gentoo.org and commits evil code into the tree. If we cannot stop this attack because we are relying on a chain of trust (and Alice is in the chain) can we at least detect the attack? verifying identity isnt the same as listing who we trust. this is the point Robin is making when he says he wants to list all trusted keys in LDAP. from there, we could create a file signed by an infra tree key and keep only the trusted keys in it. -mike
[gentoo-dev] Re: rejecting unsigned commits
http://bugs.gentoo.org/360363 -mike
[gentoo-dev] Re: rejecting unsigned commits
Il giorno gio, 24/03/2011 alle 23.42 +0100, Rémi Cardona ha scritto: However, is there a howto or something explaining how to work _efficiently_ with GPG? How do I avoid having to type my pass-phrase for every commit? Setup gpg-agent with a one-week passphrase caching and standard socket, remove gnome-keyring interface to gpg, and that's about it :P -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: rejecting unsigned commits
On Thu, Mar 24, 2011 at 6:47 PM, Diego Elio Pettenò wrote: Il giorno gio, 24/03/2011 alle 23.42 +0100, Rémi Cardona ha scritto: However, is there a howto or something explaining how to work _efficiently_ with GPG? How do I avoid having to type my pass-phrase for every commit? Setup gpg-agent with a one-week passphrase caching and standard socket, remove gnome-keyring interface to gpg, and that's about it :P indeed ... i put default-cache-ttl 99 into my ~/.gnupg/gpg-agent.conf as for gpg-agent itself, if you use net-misc/keychain, it takes care of launching gpg-agent if it's installed -mike
