Opened 22 months ago

Last modified 6 months ago

#22637 assigned defect

Find a more maintainable approach for the signing-keys page

Reported by: arma Owned by:
Priority: Medium Milestone: website redesign
Component: Webpages/Website Version:
Severity: Normal Keywords: website-content, website-bug
Cc: gk, boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Right now we have this page:
https://www.torproject.org/docs/signing-keys
which is supposed to provide an official set of keys that have signed various Tor packages in the past.

We pointed to it from
https://www.torproject.org/docs/verifying-signatures
among other places.

But people keep generating new subkeys, so the text on that page goes out of date after a month or so.

We should come up with a better way to distribute these keys, in a way that provides good enough authenticity while being easy to automate.

Maybe that's a script that gets run every so often to generate the page automatically? Maybe that's creating a gpg keyring with the right keys on it, and getting rid of the webpage?

We can think of this as part of the grand website redo, but also we can think of it as a bitesized improvement that needs to be made and can be independent of the grand website redo.

Child Tickets

TicketStatusOwnerSummaryComponent
#27699newRelease teams: please verify the website lists the correct keyApplications
#27700newPlease sign keys.txtWebpages/Website
#27702closedLink keys.txt and its signature at the signing keys pageWebpages/Website
#27703closedtpaPlease add a cronjob to regularly update our signing keys pageInternal Services/Services Admin Team
#27878needs_reviewtraumschuledocs/en/update_signing-keys.pl should not use default ~/.gnupgWebpages/Website
#28306closedtpaPlease add signing keys to db.torproject.orgInternal Services/Tor Sysadmin Team

Change History (13)

comment:1 Changed 22 months ago by cypherpunks

I would like to see key revocations explained.

For example, 05FA 4425 3F6C 19A8 B7F5 18D4 2D00 0988 5898 39A3, revoked subkey of Tor Browser Developers.

comment:2 Changed 21 months ago by hiro

Keywords: website-content website-bug added
Owner: set to hiro
Status: newaccepted

comment:3 Changed 13 months ago by hiro

Milestone: website redesign

comment:4 Changed 11 months ago by gk

Cc: gk added

comment:5 Changed 11 months ago by boklm

Cc: boklm added

Maybe that's a script that gets run every so often to generate the page automatically? Maybe that's creating a gpg keyring with the right keys on it, and getting rid of the webpage?

Providing a gpg keyring file, and generating the page automatically from this keyring sounds like a good idea. The keyring makes it easy to import the keys, and the page helps to verify them.

comment:6 in reply to:  1 Changed 11 months ago by boklm

Replying to cypherpunks:

I would like to see key revocations explained.

For example, 05FA 4425 3F6C 19A8 B7F5 18D4 2D00 0988 5898 39A3, revoked subkey of Tor Browser Developers.

You can find the corresponding bug number in the git log: #16898. We usually use sub-keys for around 2 years before switching to a new one. I think this one had to be revoked because it didn't have an expiration date.

comment:7 Changed 8 months ago by traumschule

This question came up in #tor today, I tried to answer (happy about feedback):

Hello all! I've been naively assuming to-date that @nickm signs all the Tor source bundles, but it turns out that the latest one that I'm fetching (3.3.9) is signed by Roger under C218525819F78451 - I'm wondering if there's a resource I can read to understand who is/is-not a trusted signer, please?

You can install the deb.torproject.org-keyring package: https://www.torproject.org/docs/debian.html.en
The signing keys are on this page: https://www.torproject.org/docs/signing-keys.html.en

that's a really interesting idea ... though I am a little worried, because this is on Raspbian / Raspberry Pi, and so that might not work.

On Raspbian you could retrieve the source as explained at the link above and run 'apt source deb.torproject.org-keyring'. Then the keyring is in deb.torproject.org-keyring-2018.08.06/keyrings/deb.torproject.org-keyring.gpg
Torproject could improve the authenticity of the signing keys page by actually signing it.

My proposal is to have a script referenced in the Makefile of webwml which creates text file containing a signed statement of responsibilities with all valid fingerprints and subkeys. Including this in the website would raise the credibility of the site a lite. Riseup uses a similar process for their TLS certificates.

# option 1: list all keyids
keys="0x4E2C6E8793298290 0x0E3A92E4 0x4B7C3223 0xD0220E4B 0x23291265 0xD752F538C0D38C3A 0x28988BF5 0x19F78451 0xFE43009C4607B1FB 0x6AFEE6D49E92B601 0x165733EA 0x8D29319A 0x886DDD89 0x9ABBEEC6 0x58ACD84F 0x42E86A2A11F48D36 0xB01C8B006DA77FAA 0xC82E0039 0xE1DEC577"
gpg --recv $keys

# option 2: import keys from a keyring
apt source deb.torproject.org-keyring
gpg --import deb.torproject.org-keyring-*/keyrings/deb.torproject.org-keyring.gpg

# the exact options may differ
gpg --fingerprint $keys >> docs/en/signing-keys.txt
gpg --clearsign docs/en/signing-keys.txt

related: #21808, #23586

comment:8 Changed 8 months ago by traumschule

Parent ID: #3893

It makes sense to think this together with #3893 as it suggests:

The list of keys that signs sub-components and/or email should be on a completely separate page.

comment:9 Changed 8 months ago by traumschule

Owner: changed from hiro to traumschule
Status: acceptedassigned

comment:10 Changed 8 months ago by traumschule

Status: assignedneeds_review

comment:11 Changed 7 months ago by traumschule

Resolution: fixed
Status: needs_reviewclosed

comment:12 Changed 7 months ago by traumschule

Resolution: fixed
Status: closedreopened

I was too fast, we are not done here: #27699 #27700 #27702 #27703

Last edited 7 months ago by traumschule (previous) (diff)

comment:13 Changed 6 months ago by traumschule

Owner: traumschule deleted
Parent ID: #3893
Status: reopenedassigned

This is currently not in my hands, happy to work on revisions. Unparenting to fix 'max_depth' exceeded (5) : #27698 - #27699 - #22637 - #3893 - #23266 - #21222 for children.

Note: See TracTickets for help on using tickets.