Undocumented GPG verification key.

[ejherlig]

The releases of this tool have a GPG detached signature in the archive, which implies the feature of GPG verification -- so I intended to verify it. I commend you for doing that, and wish more people would.

GPG verification establishes that the tool (or any file or text) is unchanged from the version seen by the signer, and the trust root of the verification process is the GPG key of the signer of the signature.

Two example attack methods against this verification are, 1: attacker has trojaned the tool and also compromises real signer key, and signs the trojaned tool with the real key, or 2: attacker has trojaned the tool, signs it with the attackers own key, and misleads the dowloader that the attacker key is the right signing key (various approaches like compromising the download site and altering the guidance, poisoning keyservers,).

Protection against method 1: is fully dependent on the key management of the signer, opaque to the end user, and therefore out of scope for this discussion.
Protection against method 2: it must be unmistakable to the user what the correct signing GPG key is so that the verify operation is always done with the real signer's key.

The current issue I have is how to establish trust of the key used for the detached sig in the archive.

• The project github page does not say anything about what the correct GPG signing key is

This is not helped by the fact that the key in public keyservers is from 2010, and has no signatures beyond selfsigning.

Fix: the most basic fix is just explaining the signature exists and specifying the key in the readme. For better protection against method 2, some simple options include having the key signed by known, trusted parties, and using commit signing in github to demonstrate that the readme and release are authentic