Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

README: add instructions for verifying GPG signatures #1646

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

README: add instructions for verifying GPG signatures #1646

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,6 +61,51 @@ Implementation details
* Optional runtime blinding which attempts to frustrate differential power analysis.
* The precomputed tables add and eventually subtract points for which no known scalar (secret key) is known, preventing even an attacker with control over the secret key used to control the data internally.

Obtaining and verifying
-----------------------

The git tag for each release (e.g. `v0.6.0`) is GPG-signed by one of the maintainers.
For a fully verified build of this project, it is recommended to obtain this repository
via git, obtain the GPG keys of the signing maintainer(s), and then verify the release
tag's signature using git.

This can be done with the following steps:

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`.
Comment on lines +74 to +77
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

- Consult [SECURITY.md](./SECURITY.md) for a complete listing of maintainer keys,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

per Github.
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.
Comment on lines +80 to +82
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. Retrieve the GPG key from a keyserver, e.g.
```
gpg --keyserver keyserver.ubuntu.com --recv-keys 4861DBF262123605
```
1. Clone the repository:
```
git clone https://github.com/bitcoin-core/secp256k1
```
1. Check out the latest release tag, e.g.
```
git checkout v0.6.0
```
1. Use git to verify the GPG signature:
Comment on lines +91 to +95
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

```
% git tag -v v0.6.0 | grep -C 3 'Good signature'

gpg: Signature made Mon 04 Nov 2024 12:14:44 PM EST
gpg: using RSA key 4BBB845A6F5A65A69DFAEC234861DBF262123605
gpg: Good signature from "Jonas Nick <jonas@n-ck.net>" [unknown]
gpg: aka "Jonas Nick <jonasd.nick@gmail.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 36C7 1A37 C9D9 88BD E825 08D9 B1A7 0E4F 8DCD 0366
Subkey fingerprint: 4BBB 845A 6F5A 65A6 9DFA EC23 4861 DBF2 6212 3605
```

Building with Autotools
-----------------------

Expand Down
Loading