[gentoo-amd64] Re: "For What It's Worth" (or How do I know my Gentoo source code hasn't been messed with?)

[Duncan]

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