README: add instructions for verifying GPG signatures

jamesob commented at 2:18 pm on December 11, 2024: contributor

Fixes #1644.

real-or-random added the label user-documentation on Dec 11, 2024

in README.md:77 in c850eddd25 outdated

72+This can be done with the following steps:
73+
74+1. Check the latest release on the [Releases
75+   page](https://github.com/bitcoin-core/secp256k1/releases). Determine the signing GPG ID
76+   by clicking the green icon next to the tag name. For example, in the case of v0.6.0,
77+   this would be `4861DBF262123605`.

jonasnick commented at 5:47 pm on December 13, 2024:

Ah, okay I understand our discussion in #1644 better now. You’re probably not aware that our GPG keys are in SECURITY.md? Yeah, that’s not at all obvious. So I think the first step should be to obtain the GPG public keys of all maintainers as described in SECURITY.md.

jamesob commented at 9:06 pm on December 13, 2024:

Ah yeah I did miss that, thanks. I’ll revise this change to point to that file.

real-or-random commented at 4:32 pm on December 14, 2024:

Now that you’ve added the reference to the file, why not drop this step in the GitHub web interface entirely?

I think the steps should be:

Obtain the keys in SECURITY.md
Use the command line to verify the tag.
If successful, compare the key fingerprint with a trusted source. (I think it’s a good idea to compare the full fingerprint, and not just the long key ID.)

None of these require the web (except maybe obtaining a trusted copy of the fingerprint).

in README.md:81 in c850eddd25 outdated

74+1. Check the latest release on the [Releases
75+   page](https://github.com/bitcoin-core/secp256k1/releases). Determine the signing GPG ID
76+   by clicking the green icon next to the tag name. For example, in the case of v0.6.0,
77+   this would be `4861DBF262123605`.
78+1. Cross-reference this key ID with another source controlled by its owner (e.g.
79+   https://x.com/n1ckler).

jonasnick commented at 6:00 pm on December 13, 2024:

Not sure if this step is security theater. Either this repo is legitimate and the GPG keys are correct or it’s not and will have arbitrary instructions here.

One possible justification for including this step is educational: it reminds users how to increase assurance that a GPG key they encounter for the first time is correct. In that case I’d suggest to run the fingerprint through a search engine. Using google, this gives somewhat reasonable results for sipa and myself, but not for @real-or-random.

jamesob commented at 9:05 pm on December 13, 2024:

It may be overly paranoid, but I don’t think it’s security theater. The problem we’re trying to mitigate here is a singular trust of what’s presented on Github. I think definitionally, we need to consult a source that is not Github (or something obtained from Github) in order to get additional assurance that the keys we’re verifying against are indeed your keys.

The thought experiment is “if Github is compromised, and the attacker can modify any of its content, will the instructions result in catching that?” I think consulting a second source for GPG IDs is necessary to fulfill that.

jonasnick commented at 9:14 am on December 16, 2024:

Ok, so iiuc the practical failure mode this can prevent is when instructions and SECURITY.md are obtained from two different sources somehow (or same source, at different times) and only SECURITY.md is compromised. Seems reasonable.

jonasnick commented at 6:01 pm on December 13, 2024: contributor

Thank you @jamesob. I think this is a significant improvement to our README.

jamesob force-pushed on Dec 13, 2024

jamesob commented at 9:11 pm on December 13, 2024: contributor

@jonasnick I’ve pushed some changes based on your feedback, hope it helps.

in README.md:82 in f738f383ed outdated

77+   this would be `4861DBF262123605`.
78+    - Consult [SECURITY.md](./SECURITY.md) for a complete listing of maintainer keys,
79+      per Github.
80+1. If possible, cross-reference this key ID with another source controlled by its owner (e.g.
81+   https://x.com/n1ckler).
82+    - This is to guard against the unlikely case that incorrect content is being presented by Github.com.

real-or-random commented at 4:27 pm on December 14, 2024:

It’s bad enough that we rely on GitHub, so I’d avoid links to other third-party sites. It’s up to the user to decide which source they trust, and I don’t think it’s our job to offer suggestions here. That’s bad, but it’s a fundamental problem. We cannot do much about it. (For what it’s worth, I don’t trust x.com too much.) I expect people who obtain the source code of a C library to be able to do their research.

in README.md:95 in f738f383ed outdated

90+    ```
91+1. Check out the latest release tag, e.g. 
92+    ```
93+    git checkout v0.6.0
94+    ```
95+1. Use git to verify the GPG signature:

real-or-random commented at 4:29 pm on December 14, 2024:

nit: I prefer “1. / 2. / 3.” instead of “1. / 1. / 1.”, i.e., I prefer readability of the plain text file over maintainability.

in README.md:78 in f738f383ed outdated

73+
74+1. Check the latest release on the [Releases
75+   page](https://github.com/bitcoin-core/secp256k1/releases). Determine the signing GPG ID
76+   by clicking the green icon next to the tag name. For example, in the case of v0.6.0,
77+   this would be `4861DBF262123605`.
78+    - Consult [SECURITY.md](./SECURITY.md) for a complete listing of maintainer keys,

real-or-random commented at 4:34 pm on December 14, 2024:

“per Github” assumes that the user has obtained the git repo from GitHub, which is likely but not the only possibility.

jamesob force-pushed on Feb 4, 2025

jamesob commented at 4:27 am on February 4, 2025: contributor

Pushed a more succinct version that I think covers all feedback

in README.md:77 in 9180727093 outdated

72+This can be done with the following steps:
73+
74+1. Obtain the GPG keys listed in [SECURITY.md](./SECURITY.md).
75+2. If possible, cross-reference these key IDs with another source controlled by its owner (e.g.
76+   social media, personal website).
77+    - This is to mitigate the unlikely case that incorrect content is being presented by this repository.

real-or-random commented at 11:13 am on February 4, 2025:

if you touch this again, no need to use a list:

02. If possible, cross-reference these key IDs with another source controlled by its owner (e.g. social media, personal website).
1   This is to mitigate the unlikely case that incorrect content is being presented by this repository.

jamesob commented at 1:20 pm on February 6, 2025:

Fixed

real-or-random approved

real-or-random commented at 11:14 am on February 4, 2025: contributor

ACK 918072709397da5cbe8d2a04b9defd343539ceeb

README: add instructions for verifying GPG signatures b682dbcf84

jamesob force-pushed on Feb 6, 2025

sipa commented at 1:22 pm on February 6, 2025: contributor

ACK b682dbcf845d80f69c4e2d8243c90dd48006a4c1

jonasnick approved

jonasnick commented at 12:53 pm on February 10, 2025: contributor

ACK b682dbcf845d80f69c4e2d8243c90dd48006a4c1

jonasnick merged this on Feb 10, 2025

jonasnick closed this on Feb 10, 2025

README: add instructions for verifying GPG signatures #1646