The stuff about GPG and the public keyservers remind me of the Gnus, GPG and GMail Guide I wrote a while back. At one point I write:

I'm also going to "trust" them all, so I’m using this setting:

# More like "Web of Mistrust", amirite??
trust-model always


@kensanata does that basically say
"GPG is only used by nerds who don't leave their basement, so there's no risk of them meeting a stranger, let alone signing a stranger's key" ?

@Wolf480pl Maybe. Do you feel a friend of a friend is also your friend? Or: do you feel that you trust your friend to be as good a judge of human character as you are? I guess I just don’t think trust is that transitive. Perhaps I have a poor taste In friends. Friend-of-a-friend certainly seems like a very bad idea to me. And indeed, newer systems like Threema don’t have that.

oh come on, don't tell me you don't know the difference between validity and trust...

In OpenPGP:

validity - does this "kensanata" cert really belong to kensanata?

trust - if kensanata says that is enkiv2's cert, do I trust that kensanata did check enkiv2's identity properly, and I accept his assertion?

Validity is transitive, if all the middle nodes are trusted.

But trust is not transitive.

The thing is, at higher scale, it's impractical.
Maybe i know you so I can tell gpg how much I trust you to be able to verify keys properly.

But if the chain is longer and includes people I don't know, how do I know whether they're competent at verifying other people's pubkeys? I can't trust them, but if I don't trust them, the chain is useless...

Alternatively you can try out trust-model tofu. It’s trust on first use so similar to what SSH uses. You’ll see warnings for new keys but the keys would get more and more “trusted” as you use them (for verification/encryption etc.)

@wiktor What’s the effective difference, though? My solution means I need to add each key manually, and when I do I assume that I did my best to verify the identity. With tofu... I still add them and acknowledge the warning, but over time suddenly keys my contacts signed are also trusted? I just don’t feel that trust is transitive that way, not for me, at least. Perhaps I have a poor choice of friends and email contacts.

@kensanata I don't think the problem is transitivity as such; more that trust is a) not binary but analog and b) multi-dimensional.

By multi-dimensional I mean: I'd trust the committee of my astronomy society to say that the key of another member is valid but wouldn't trust them to say that a key supposedly of my bank is valid. Trust in the two things are orthogonal.

A problem I have with PGP is that it grossly over-simplifies this sort of thing.

@kensanata The advantage of pure tofu [¹] is that you get alerted if a message from a correspondent suddenly arrives with a different key.

[¹] By pure tofu I mean without associated web-of-trust trusting (other than maybe as a hint to help you with the decision whether to trust on first use. Something like “Fred has signed this message with a new key (which has been signed by Alice and Bert), trust (Y/n)?”).


@edavies I must be misunderstanding how this works. I add all the keys I trust manually. So now you send me a message signed with a new key that isn't in my key ring: am I going to have a fundamentally different experience than a tofu user? Aren't both going to tell me that there is an unknown key here? Perhaps the SSH analogy is misleading, here.

@edavies I think this is what is going to happen: I'm getting an email from address X, signed with a new key, and now the mail client tries to verify the signature and doesn't find the public key in my keyring. I get a message saying as much. Right? Or am I confused somehow?

Technically there is no problem with your workflow and some distros operate in the same fashion: by having a “curated” keyring. If you keep it clean at all times all it is good.

Unfortunately this can fail in unexpected ways, for example GnuPG once had auto-key-retrieve enabled by default [0]. That would pollute your clean keyring by keys used for signature verification, pulled automatically from keyservers. Some other tools, such as Enigmail, can fetch keys automatically. If you watch your keyring constantly and clean it up when it gets messy it will be OK.


An alternative used by other distros, such as Arch Linux, is to locally sign key on import and use regular pgp trust model (gpg --quick-lsign-key $KEY).

@wiktor @edavies Ah, thanks for the descriptions for these alternative workflows. Interesting.

@kensanata Sorry, misunderstood your model: as written it looked like you were just going to trust all keys, not just the ones in your keyring!

But, as @wiktor says, keys can show up in your keyring for various reasons. Enigmail seems to fetch them through WKD [¹], for example. I'm not sure if it adds ones seen as Autocrypt headers (as the only Autocrypt headers I've noticed receiving are for keys I already have).


Ed, would you consider publishing your WKD creator code somewhere and attaching some open-source license? I think it looks great and it would be useful for a wider audience :)

@wiktor Thanks. The code's there for a simple copy/paste and I say public domain/MIT licence in the last paragraph. Packaging it any more than that doesn't seem worthwhile; I'd think most people would want/need to tweak it a bit.

(Actually just been thinking about the implications of a wider copyright/licence statement for the whole site.)

Ah, right. I looked for the license but I don’t know why did I omit the last paragraph… I’ll rely on CTRL+F the next time.

I usually use CC for content: and APL for code:

Thanks and see you! 👋

@wiktor For content I was thinking CC-BY-NC-SA. NC to have a comeback to sites which mirror pages for clicks, etc. If anybody wants commercial use of anything they can just ask.

Sign in to participate in the conversation

Octodon is a nice general purpose instance. more