there's no reason to allow people to commit unsigned Manifests anymore. time to get the ball rolling further by forcing all devs to do so. with cvs, we can only reject the Manifest file. with git, we'll be able to reject the whole changeset :). i think this is fine for both as people who dont commit Manifests will get yelled at.
oh, and the rejection notice probably should include URLs to the relevant Gentoo documentation for creating said keys and enabling them in your make.conf
Is the relevant documentation up? If so, where?
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=6
we'll probably also want to (eventually?) reject SHA1 signed files. i see a lot of people still committing with that. unscd/Manifest:Hash: SHA256 usb_modeswitch/Manifest:Hash: SHA1
(In reply to comment #4) > we'll probably also want to (eventually?) reject SHA1 signed files. i see a > lot of people still committing with that. > > unscd/Manifest:Hash: SHA256 > usb_modeswitch/Manifest:Hash: SHA1 We should add to the documentation how to configure gpg.conf. Something like default-key D0455535 personal-digest-preferences SHA256 SHA384 SHA512 where default-key must be the key provided to infra.
(In reply to comment #5) > where default-key must be the key provided to infra. No, where you MUST upload it to a specified keyserver, and it must be in your LDAP (you have full ability to edit the field yourself).
no, not the key that is in LDAP. that is your personal GPG key, usually not the one used for signing packages. we should however require that the one in LDAP sign the one you're using for signing packages. so we want to reject: - unsigned manifests - SHA1 digests long term, we'll want to generate an e-mail warning on: - key not on key server - key is not the one in LDAP and is not signed by the one in LDAP
(In reply to comment #7) > no, not the key that is in LDAP. that is your personal GPG key, usually not > the one used for signing packages. we should however require that the one in > LDAP sign the one you're using for signing packages. The field in LDAP explicitly permits multiple keys, and ALL of your keys, used for email or package-signing should be listed. If you want to use N separate keys, or just one key, that's up to the developer, and has no impact on verification. > so we want to reject: > - unsigned manifests > - SHA1 digests > > long term, we'll want to generate an e-mail warning on: > - key not on key server > - key is not the one in LDAP and is not signed by the one in LDAP Agreed.
forcing people to update their LDAP is kind of a pain. and i dont see the point if the key they're signing with is itself signed by a key in LDAP. we want to automate this as much as possible, and allowing either LDAP or a signing trail seems to accomplish that.
other issues to reject commits: - key is expired (to be paranoid about the case of someone stealing an expired key, turning their local clock back, and then generating new signatures) - key is revoked
(In reply to comment #9) > forcing people to update their LDAP is kind of a pain. and i dont see the > point if the key they're signing with is itself signed by a key in LDAP. In terms of validation, I have a partial script that queries LDAP for all key UIDs, and builds a keyring with that. Then you can use the keyring to validate Manifests. > we want to automate this as much as possible, and allowing either LDAP or a > signing trail seems to accomplish that. Signing trail means that we have to chase down keys during validation. Also, I'd be concerned that chasing validation opens a serious concern if I do key-signing with mallory@evildomain.com, and he manages to get a Manifest into the system. Under your proposal, his signature is valid.
the e-mail address is irrelevant. only the actual key is. so unless that random dude got your private key, i dont see how he could spoof your signature.
(In reply to comment #9) > forcing people to update their LDAP is kind of a pain. and i dont see the > point if the key they're signing with is itself signed by a key in LDAP. (In reply to comment #12) > the e-mail address is irrelevant. only the actual key is. so unless that > random dude got your private key, i dont see how he could spoof your signature. You're contradicting yourself here. Keys: A = robbat2 M = mallory 1. Mallory and robbat2 met at key-signing event, and there is a certification (key signature) A<->M. 2. A is listed in LDAP. 3. Mallory attacks the system somewhere and injects a Manifest signed with M. Under your proposal of comment #9, his Manifest is VALID, since his key was legitimately certified by mine.
his manifest is perfectly valid. your point isnt whether it's valid, it's whether we should be trusting it. those are two different things. the only way that guy could have gotten his manifest onto the server is if he has commit access. which means he is trusted.
as Alec pointed out, if we want to protect against even breakins to our commit server, or more likely mitm attacks against rsync, having the key list be explicit and included with the tree would simplify everything. so i guess requiring people to list all their keys in LDAP is fine as you could then sign the list with a master key and include it in the portage tree as part of the normal sync. or some other distribution method.
What is the status of this proposal?
No CVS, no signed Manifests anymore.
