Find a more maintainable approach for the signing-keys page

[arma]

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.

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

[boklm]

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.

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

[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

[traumschule]

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.

[traumschule]

​https://github.com/torproject/webwml/pull/34

[traumschule]

merged: ​http://expyuzz4wqqyqhjn.onion/docs/signing-keys.html.en

[traumschule]

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

[traumschule]

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.

[teor]

Change tickets that are assigned to nobody to "new".