Check-trustpaths: find and check code signatures in the PGP web of trust | Hacker News Reader

Check-trustpaths: find and check code signatures in the PGP web of trust

gitlab.com

36 pointsjnxx12 comments

Remember that the trust relationship in OpenPGP is not transitive. If you know that Alice's key is valid and you trust Alice, then if Alice signs Bob's key, you know that Bob's key is valid. However, unless you also personally trust Bob, then you cannot trust any signatures that Bob makes. (Unless Alice's signature also indicates trust in Bob; but this is not the common situation, think of e.g., keysigning parties.) Hence, if you have a path from you to Carol going through Alice and Bob, and you trust Alice but you do not know Bob, then you have no guarantees about the validity of Carol's key (Bob may have signed a phoney key).

Of course, checking paths in the Web of Trust is not entirely useless, because a key which is connected to you probably has more chances to be valid. However, it offers no strong guarantee on trust unless you personally trust all intermediates along that chain.

The trust values depend on the configuration of GnuPG and the trust model which is used. In the "web of trust" model, it is possible that one or several intermediaries sign a key and this key can become trusted. This is, of course, not perfect, but an approximation.

It is true that the usefulness of such indirect links quickly becomes much weaker than a direct link. What the tool tries to solve is to make an assessment for software, where direct signatures are often not practical.

> it is possible that one or several intermediaries sign a key and this key can become trusted

Yes, but as far as I understand this only occurs if you give them a trust rating (e.g., I marginally trust). If a key K is signed by multiple other keys which you know are valid but where you have no reason to trust the holders (and don't claim to trust them), then (as far as I understand) GnuPG will never infer that K is valid (and rightfully so).

Here is a relevant section of the gnupg manual:

https://www.gnupg.org/gph/en/manual.html#AEN385

I think the concept was developed by Hal Finney; IIRC there is somewhere an email in which he describes it.

Thanks for the link. As far as I understand, it agrees with my interpretation.

Another similar tool:

https://www.lysator.liu.se/~jc/wotsap/

It is actually based on that one:

http://pgp.cs.uu.nl/

(It uses a web API which the server provides.)

Watch out, this sets random keys to ultimate trust.

https://gitlab.com/jnxx/check-trustpaths/issues/1

Thanks, will check in the next hours.

Issue confirmed - the trusted-key option in gnupg sets the given key permanently to be trusted, not temporarily as was incorrectly assumed.

I apologize! To remedy the issue, please clear the trust value of key with ID "DAFFB000" by calling

gpg edit-key DAFFB000

and then command "trust", set value to "unknown", save and quit. After that, the trust value should be "unknown". If in any doubt, restore your trustdb from backup.

Update follows soon.

Hello, this is probably an error.

First, the program needs to use a starting key to start trust paths, the "from" key. Because most people probably are not connected to the web of trust (or, more specifically, to the "strong set" of the web of trust), it tries to set a reasonable default.

This default is probably the best-connected key, the "c't crypto campaign" key. The connections are analyzed and shown here:

http://www.lysator.liu.se/~jc/wotsap/leafoftrust.html

The connections are so strong because c't is a German magazine (website www.heise.de) which has been promoting the use of PGP for years, and worked as kind of an ad hoc CA for tech people.

The "FROM" key can be set by configuration options, and in fact anyone who uses this should set it a an own key he trusts, because it is not a good idea to introduce single points of failure in the trust web.

Said all that, the program should NOT, under NO circumstance, change the local trust DB of the user, because this could affect trust decisions. If it does that, this is a significant and serious error, which I will fix as soon as possible. Please, do not use this for production purposes before it's checked and fixed.

I'll check and if required fix that today (can't do it right now), please have a bit of patience.

And thanks for the feedback!

Reply on news.ycombinator.com