Expired subkey warning on Tor Browser GPG verification

gpg verification on tor-browser warns about expired subkey:

gpg --verify tor-browser-linux64-12.5.4_ALL.tar.xz.asc
gpg: assuming signed data in 'tor-browser-linux64-12.5.4_ALL.tar.xz'
gpg: Signature made mer 13 set 2023, 20:27:50 CEST
gpg:                using RSA key 613188FC5BE2176E3ED54901E53D989A9E2D47BF
gpg: Good signature from "Tor Browser Developers (signing key) <torbrowser@torproject.org>" [unknown]
gpg: Note: This key has expired!
Primary key fingerprint: EF6E 286D DA85 EA2A 4BA7  DE68 4E2C 6E87 9329 8290
     Subkey fingerprint: 6131 88FC 5BE2 176E 3ED5  4901 E53D 989A 9E2D 47BF

added Signing label

assigned to @boklm

changed title from Expired subkey used to sign Tor Browser to Expired subkey warning on Tor Browser GPG verification

It appears that new subkeys have been generated in the past when expiration was coming - i'm curious if someone remembers/knows why that method is used, instead of just extending the expiration date on the existing key? There are pros/cons for each, but I've found that often people just don't even know you can extend the expiration.

The subkey is kept on our signing machine, while the main key is kept offline, so it's useful to create a new subkey to rotate the key we use.

Maybe for next time we can switch to a new subkey while the old one is still valid for a few months, so that last release can be verified without using an expired subkey.

boklm (@boklm):

boklm commented on a discussion: #40957 (comment 2945947)

The subkey is kept on our signing machine, while the main key is kept offline, so it's useful to create a new subkey to rotate the key we use.

Maybe for next time we can switch to a new subkey while the old one is still valid for a few months, so that last release can be verified without using an expired subkey.

That's what we actually used to do a couple of years back to avoid the exact problem which we encountered (again) in this issue... :)

The subkey is kept on our signing machine, while the main key is kept offline, so it's useful to create a new subkey to rotate the key we use.

Makes sense, thanks for the explanation!

Maybe for next time we can switch to a new subkey while the old one is still valid for a few months, so that last release can be verified without using an expired subkey.

Seems like a good idea :)

...

On 2023-09-21 07:25:02, boklm (@boklm) wrote:

And maybe once this instance is fixed we can open a new related issue "Update signing keys", setting its due date 2 weeks before the subkey expiration and keeping it open, up-to-date & rolling indefinitely

yes, we should do for all our keys

assigned to @richard and unassigned @boklm

We might need related issues on TPA and or web (a user said on IRC the key has not been updated on TPO).

They added this link: https://github.com/micahflee/torbrowser-launcher/issues/700#issuecomment-1727392723

We might need related issues on TPA and or web (a user said on IRC the key has not been updated on TPO).

We have not updated the key yet. We are still trying to get access to the key.

Sorry, my bad. They were saying the key was updated on openpgp.org, but I haven't checked myself.

Expiration date on the subkey has been extended by 5 months.

The ticket to update it in wkd is tpo/tpa/team#41333 (closed).

mentioned in issue tor-browser#42127 (closed)

marked tor-browser#42127 (closed) as a duplicate of this issue

marked this issue as related to tor-browser#42127 (closed)

mentioned in merge request !821 (merged)

mentioned in issue #40964 (closed)

marked this issue as related to #40959 (closed)

marked this issue as related to #40960 (closed)

added All Platforms Build System Task labels

closed

marked this issue as related to #40965 (closed)

marked this issue as related to #40966 (closed)