openresty / openresty/openresty.org

Specify more GPG key bits — otherwise the key can be faked? Someone already did

Open
#171 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
1.3k
Forks
293
Avg merge
2d 20h
Merged PRs (30d)
2

Description

On the website, https://openresty.org/en/download.html, there's this:

Source Code Releases
All the releases are signed by the public PGP key A0E98066 of Yichun Zhang.

That's 32 bits to identify a key — and that's a bit few bits; others can generate fake keys with the same last 32 bits.

In fact, someone did:

$ gpg --keyserver keyserver.ubuntu.com --keyserver-options timeout=10 --recv-key A0E98066
gpg: key A84A5A40A0E98066: public key "Totally Legit Signing Key <mallory@example.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

As you can see, someone has generated a fake key that ends with A0E98066.

(That's Ubuntu's keyserver, which I tried, when MIT didn't work; they're supposed to be in sync with each other I think?)

What do you think about specifying the full key ID on the website, or the last 64 bits?

There's an old issue and merged PR related to that,
issue: https://github.com/openresty/openresty.org/issues/30 "Add information to the GPG key"
PR: https://github.com/openresty/openresty.org/pull/32 "Add information about public key to verify release files"

but somehow the changes in the PR seems to have gotten lost during the years. Anyway, in the PR, I see that the last 64 bits of the key are: 0xB550E09EA0E98066

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at https://openresty.org/en/download.html and compare its GPG-key wording with issue 30 and merged PR 32. Confirm the full or last-64-bit key ID from the issue, update the displayed key information, and verify that the page no longer identifies the signing key using only A0E98066.

Written by the indexing model from the issue text.

Assessment

Tech stack
html
Domain
documentation, security
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.