New release exe not verifying with sig. Using gpg.

[ezswan]

Hello,

I downloaded the most recent release. 2.0.0 and its corresponding sig. Ran through gpg. Not certified user and unable to verify the downloads. I assume I am either not doing this right, or people just give this a pass?

let me know. Thanks

[skeeto]

Sounds like you're missing a step. To double check, just now I downloaded both 2.0.0 artifacts, and the signatures verified as expected. From your error it looks like a keyring management issue along with misinterpreting the output: You have my key, probably from my blog, but it's untrusted. If true, you would see "Good signature from" but then "key is not certified". Despite the ominous warning, "gpg --verify" will still have succeeded (!) according to the exit code. The result you _don't_ want is "BAD signature from" which indicates the signature doesn't match. If you don't have my key ("No public key"), you can find it on my blog, after which you'll be in the position above. I've been using it for five years (verifiable via the Wayback Machine) and have signed many software releases with it, so it has an established reputation. It's one of the more carefully guarded cryptographic keys out there, and at this moment the private key is stored only in an analog medium at one location. As for the warning: I don't publish my key on any keyservers, and it's not connected to the web of trust strong set, not even weakly. (I've probably never met anyone in person who owns a PGP key.) You'll need to inform GnuPG how much you trust my key using the --edit prompt "trust" command: $ gpg --edit nullprogram.com gpg> trust Don't worry too much about the specifics. Most of PGP, especially GnuPG, is security LARP. Unlike PGP encryption, which is a joke, PGP signatures are reasonably constructed and the de facto standard for signing arbitrary files. I provide signatures so that those who are so inclined can reliably and strongly verify that artifacts have gone from me to them without intermediate tampering. That includes between past me and future me! It's possible that you're the first person besides myself to actually check my release signatures. So thanks for testing them!

[ezswan]

Yea, I do not verify that often, so the process is a bit odd to me. I did so because of certain posts in "issues," about virus software detecting certain things. False positives and others.

I did not acquire your public key via your blog. I actually was trying to find it throughout this documentation to no avail. Ran decrypt/verify with PGP front end app/program. Came up missing public key, which is where I was trying to find it. Couldn't. So, it gave me the option to search. It came up with your name and a fingerprint key, and your Key-ID.

But its "not a trusted signature." I do not know how you get the trusted status. I think i can certify you trust but i do not know if that is just for my local PGP.

Basically, nothing said, "verified." Simply, "untrusted." But nothing said "bad."

I think it's good.

Also, Malwarebytes is flagging the debugger as malware. I think that is a false positive.

[skeeto]

I do not know how you get the trusted status.

The "--edit" and "trust" commands I showed do this, and it only affects your personal keyring. There are no authorities in the PGP ecosystem to certify keys. I could list my key in the documentation, but on its own without context it wouldn't serve a useful purpose. It would just be some random key and verification would convey no meaning. Verification is only meaningful if you know something about my key beforehand. (Though perhaps I should toss a tagged copy in the repository, as Junio Hamano does with Git.) For most people, HTTPS is doing all the cryptographic heavy lifting by preventing tampering (i.e. by an ISP or government) on route between themselves and GitHub, and entity they know.

I think that is a false positive.

Yes, those are all false positives. Since the false positives come from overconfident AI analysis, we could even call them hallucinations.

[ezswan]

I could list my key in the documentation, but on its own without context it wouldn't serve a useful purpose.

So, I disagree, if there is no purpose to have the public key in your documentation, then what is the purpose of the sig files?