I'd like to see a common gpg-key for GLSAs. Currently, the GLSAs carry keys from different gentoo-devs.
IMHO it would be a good idea to use a common key for all GLSAs, liek "email@example.com" instead of "$firstname.lastname@example.org".
Would make keymanagment much easier and one single key is always easier to verify.
You'd only need to import one key instead of importing a new key everytime a new dev issues a GLSA.
We'd also have to revoke the key any time a dev left the security team, which would be a much more disruptive process. At this point, we have no plans to use a shared key.
Why? The dev, who writes the GLSA, simply sends it the one who is responsible for the GLSAs/key. He now signs the GLSA and sends it. Only one person would have to know the key.
Look at the Debian DSAs.
OK, you'd have to change it if the guy for GLSAs leaves the team, but that would be not that big a problem.
If you got tons of keys, how do I know the key is valid, e.g. from a gentoo-dev? There are new keys/devs quite often. IMHO that's much more dangerous, since you get lazy and won't verify the keys.
And security.gentoo.org didn't give me a list of valid keys on first glance.
There is no "one guy" that sends GLSAs. There are several. If we had a shared key, each of them would have to have the private key and passphrase. If any of them left, we'd have to revoke the existing key and create a new one. What about all the GLSAs signed with the old keys? They're now invalid. Do we re-sign those? Then any GLSA issued via email or posted to a site we don't control will appear as invalid.
I don't disagree that having one key would be *convenient*. However, I don't see how it's feasible given the way we currently publish GLSAs.
I don't see why it would be difficult to use one single key (OK, the issuer doesn't send the GLSA himself but sends it to the "glsa-sending-guy who knows the passphrase" first.
But if you want to stick with the many-keys-system: How do I verify the keys actually belong to a dev who is allowed to issue GLSAs? Nothing on security.gentoo.org on first glance.
ALl keys for security devs should be on the public keyservers. If they aren't, that's a bug that should be fixed.
Additionally, you can see all Gentoo dev key IDs here:
I will add a link on the gentoo security page that points back to gentoos roll-call page to make this process eaiser for people to verify.
> ALl keys for security devs should be on the public keyservers.
> If they aren't, that's a bug that should be fixed.
But a key with the name $email@example.com on a keyserver that hasn't been signed by anybody (I looked at the keys, and the three I checked weren't signed) doesn't tell me *anything*.
I don't know if this person is actually a gentoo dev and it doesn't tell me if that person is authorized to issue GLSAs.
Well, we can't sign any keys without meeting folks in person. (at least, we shouldn't...) Most of us live in different countries, so it's difficult to meet for key signing parties.
My key is signed by a number of other devs, but only because I've been around for a while.
As for who is/isn't a gentoo dev, if you see their name and GPG key ID listed on our web site, then it's a reasonable assumption that any GLSAs sent by that same person with that same key ID are gentoo devs.
I don't think a shared key is a viable option for us, but I'm open to other suggestions on ways to improve this process so if you have some ideas, please let us know.
RCS file: /var/cvsroot/gentoo/xml/htdocs/security/en/index.xml,v
retrieving revision 1.18
diff -u -b -B -w -p -r1.18 index.xml
--- index.xml 14 Nov 2004 16:14:32 -0000 1.18
+++ index.xml 14 Nov 2004 16:20:07 -0000
@@ -221,6 +221,8 @@ encrypted mail one of the following secu
-- Bringing advanced security to Gentoo Linux</li>
<li><uri link="/proj/en/server/">Gentoo Server Project</uri>
-- Focusing on server-specific issues, such as security and stability</li>
+<li><uri link="/proj/en/devrel/roll-call/userinfo.xml">Active Developer List</uri>
+ -- Active Developer List including GPG keys which can be used to verify GLSAs</li>