README: add instructions for verifying GPG signatures #1646
Conversation
| 1. Check the latest release on the [Releases | ||
| page](https://github.com/bitcoin-core/secp256k1/releases). Determine the signing GPG ID | ||
| by clicking the green icon next to the tag name. For example, in the case of v0.6.0, | ||
| this would be `4861DBF262123605`. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Ah yeah I did miss that, thanks. I'll revise this change to point to that file.
There was a problem hiding this comment.
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).
README.md
Outdated
| 1. Cross-reference this key ID with another source controlled by its owner (e.g. | ||
| https://x.com/n1ckler). |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
jamesob
force-pushed
the
jamesob-24-12-doc-gpg-verify
branch
from
c850edd to
f738f38
Compare
|
@jonasnick I've pushed some changes based on your feedback, hope it helps. |
| 1. If possible, cross-reference this key ID with another source controlled by its owner (e.g. | ||
| https://x.com/n1ckler). | ||
| - This is to guard against the unlikely case that incorrect content is being presented by Github.com. |
There was a problem hiding this comment.
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.
| 1. Check out the latest release tag, e.g. | ||
| ``` | ||
| git checkout v0.6.0 | ||
| ``` | ||
| 1. Use git to verify the GPG signature: |
There was a problem hiding this comment.
nit: I prefer "1. / 2. / 3." instead of "1. / 1. / 1.", i.e., I prefer readability of the plain text file over maintainability.
| 1. Check the latest release on the [Releases | ||
| page](https://github.com/bitcoin-core/secp256k1/releases). Determine the signing GPG ID | ||
| by clicking the green icon next to the tag name. For example, in the case of v0.6.0, | ||
| this would be `4861DBF262123605`. |
There was a problem hiding this comment.
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).
| page](https://github.com/bitcoin-core/secp256k1/releases). Determine the signing GPG ID | ||
| by clicking the green icon next to the tag name. For example, in the case of v0.6.0, | ||
| this would be `4861DBF262123605`. | ||
| - Consult [SECURITY.md](./SECURITY.md) for a complete listing of maintainer keys, |
There was a problem hiding this comment.
"per Github" assumes that the user has obtained the git repo from GitHub, which is likely but not the only possibility.
Fixes #1644.