Mark Knecht posted on Thu, 07 Aug 2014 11:16:23 -0700 as excerpted: > From the comment about the Release Engineering site, I think that's > here: > > https://www.gentoo.org/proj/en/releng/ > > And the keys match with is good. > > Anyway, running the first command is fine. The second command wants me > to make a choice. For now I chose to 'ultimately trust'. (Aren't I > gullible!?!)
[...] > Please decide how far you trust this user to correctly verify other > users' keys (by looking at passports, checking fingerprints from > different sources, etc.) > > 1 = I don't know or won't say > 2 = I do NOT trust > 3 = I trust marginally > 4 = I trust fully > 5 = I trust ultimately > m = back to the main menu > > Your decision? 5 > Do you really want to set this key to ultimate trust? (y/N) y GPG is built on a "web of trust" idea. Basically, the idea is that if you know and trust someone (well, in this case their key), then they can vouch for someone else that you don't know. At various community conferences and the like, there's often a "key signing party". Attending devs and others active in the community check passports and etc, in theory validating the identity of the other person, then sign their key, saying they've checked and the person using this key is really who they say they are. What you're doing here is giving gpg some idea of how much trust you want to put in the key, not just to verify that whatever that person sends you did indeed get signed with their key, but more importantly, to what extent you trust that key to vouch for OTHER keys it has signed that you don't know about yet. If an otherwise unknown-trust key is signed by an ultimate-trust key, it'll automatically be considered valid, tho it won't itself be trusted to sign /other/ keys until you specifically assign a level of trust to it, too. OTOH, it'd probably take a fully-trusted key plus perhaps a marginally trusted key, to validate an otherwise unknown key signed by both but not signed by an ultimately-trusted key. And it'd take more (at least three, maybe five or something, I get the idea but have forgotten the specifics) marginal trust key signatures to verify an otherwise unknown key in the absence of a stronger-trust key signature of it as well. Don't know or won't say I think means it doesn't count either way, and do NOT trust probably counts as a negative vote, thus requiring more votes from at least marginal-trust signatures to validate than it would otherwise. I'm sure the details are in the gpg docs if you're interested in reading up... Meanwhile, the key in question here is the gentoo snapshot-validation key, which should only be used to sign the tree tarballs, not a personal key, and gentoo should use a different key to, for instance, sign personal gentoo dev keys, so you're not likely to see it used to sign other keys and the above web-of-trust stuff doesn't matter so much in this case. OTOH... (more below) > Please note that the shown key validity is not necessarily correct > unless you restart the program. > gpg> check uid Gentoo Portage Snapshot Signing Key > (Automated Signing Key) > sig!3 96D8BF6D 2011-11-25 [self-signature] > 6 signatures not checked due to missing keys > I'm not sure how to short of a reboot 'restart the program' That's simply saying that you're in gpg interactive mode, and any edits you make in that gpg session won't necessarily show up or become effective until you quit gpg and start a new session. For example, I believe if you change the level of trust of some key, then in the same gpg interactive session check the validity of another key that the first one signed, the edit to the trust level of the first key won't necessarily be reflected in the validity assigned to the second key signed by the first. If you quit gpg it'll write the change you made, and restarting gpg should then give you an accurate assessment of the second key, reflecting the now saved change you made to the trust level of the first key that signed the second. > nor what the line [means:] > > 6 signatures not checked due to missing keys That simply indicates that the gentoo key is signed by a bunch of (six) others, probably gentoo infra, perhaps the foundation, etc, that if you had a larger web of trust already built, would vouch for the validity of the portage snapshotting key. Since you don't have that web of trust built yet, you gotta do without, but you gotta start somewhere... ... Which is the "more below" I referred to above. The snapshot- validation key shouldn't be used to sign other keys, because that's not its purpose. Restricting a key to a single purpose helps a bit to keep it from leaking, but more importantly, restricts the damage should it indeed leak. If the snapshotting key gets stolen, it means snapshots signed by it can be no longer trusted, but since it's not used to sign other keys, at least the thief can't use the stolen key to vouch for other keys, because the key isn't used for that. At least... he couldn't if you hadn't set the key to ultimate trust, that you indeed trust it to vouch for other keys, alone, without any other vouching for them as well. So I'd definitely recommend editing that key again, and reducing the trust level. I /think/ you can actually set it to do NOT trust for the purpose of signing other keys, since that is indeed the case, without affecting its usage for signing the portage tree snapshots. However, I'm not positive of that. I'd test that to be sure, and simply set it back to "don't want to say" or to "marginally", if that turns out to be required to validate the snapshot with it. (Tho I don't believe it should, because that would break the whole way the web of trust is supposed to work and the concept of using a key for only one thing, not letting you simply accept the signature for content signing, without also requiring you to accept it as trustworthy for signing other keys.) I believe I have a different aspect of your post to reply to as well, but that can be a different reply... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
