README: add instructions for verifying GPG signatures #1646

pull jamesob wants to merge 1 commits into bitcoin-core:master from jamesob:jamesob-24-12-doc-gpg-verify changing 1 files +45 −0
  1. jamesob commented at 2:18 pm on December 11, 2024: none
    Fixes #1644.
  2. real-or-random added the label user-documentation on Dec 11, 2024
  3. 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).

  4. 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.
  5. jonasnick commented at 6:01 pm on December 13, 2024: contributor
    Thank you @jamesob. I think this is a significant improvement to our README.
  6. README: add instructions for verifying GPG signatures f738f383ed
  7. jamesob force-pushed on Dec 13, 2024
  8. jamesob commented at 9:11 pm on December 13, 2024: none
    @jonasnick I’ve pushed some changes based on your feedback, hope it helps.
  9. in README.md:82 in f738f383ed
    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.
  10. in README.md:95 in f738f383ed
    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.
  11. in README.md:78 in f738f383ed
    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.

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin-core/secp256k1. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-22 01:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me