#28971 closed defect (not a bug)

(Sub)key rotation sometimes break downstream projects

Reported by: ahf Owned by: tbb-team
Priority: Medium Milestone: Tor: unspecified
Component: Applications/Tor Browser Version: Tor: unspecified
Severity: Normal Keywords:
Cc: arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Micah's Torbrowser Launcher (https://github.com/micahflee/torbrowser-launcher/) seems to be using the Tor Browser Teams' signing key (0x4E2C6E8793298290), but sometimes this key gets new sub-keys added, which isn't included by torbrowser-launcher in time before a new version of Tor Browser, which uses the new subkey for signing, is released.

This leads to breakage for the user and a slightly worrying error message ("You might be under attack").

  1. Do we currently have a policy for the signing key (and subkeys) for when they are rotated/have new subkeys?
  2. Do we currently have a place where the new subkeys are announced? Does potential downstream maintainers have a reasonable amount of time to update their software to handle this key rotation?
  3. Do we have a location where torbrowser-launcher can fetch this PGP key automatically (maybe on TPO infrastructure for downstream maintainers to fetch and include in their code repositories?) It sounds like gpg --recv-keys sometimes fail?

If the answers to some of the above questions are no, is that something we might want to change in the future?

Related tickets from torbrowser-launcher:

Related random forum post with the same issue from some distribution:

Child Tickets

Change History (4)

comment:1 Changed 10 months ago by arma

Thanks for getting us started here ahf.

pub   4096R/4E2C6E8793298290 2014-12-15 [expires: 2020-08-24]
uid                          Tor Browser Developers (signing key) <torbrowser@torproject.org>
sub   4096R/EB774491D9FF06E2 2018-05-26 [expires: 2020-09-12]

It looks like the master signing key (not just the subkey) is due to expire in 20 months. So we are on track for another surprise for all the various distros and packages that try to automate checking the signature.

The trouble for torbrowser-launcher in particular is that it seems to hard-code a key and then get included in a stable distro, and then users of that stable distro are screwed once the key changes.

So far we've just been blaming those users for wanting to use torbrowser-launcher, but I wonder if we can do better. In particular, I hope we can decide on a policy for the tor browser signing key that is maximally predictable to downstream automation (something like "the master key will last forever, but you should expect that it will get new subkeys periodically, but we promise to publish each new subkey 12 months before we start using it, and also here is a torproject.org https url where the current full key will always be available") and then get good at sticking to our policy.

comment:3 Changed 10 months ago by gk

We have a policy even though it is not written down yet.

Assuming we are not aware of any key compromise the master key's expiry date will get updated once it is about to run out and new subkeys get rotated once their expiry date is about to run out. "Is about to run out" is a bit vague but the idea is to make sure the current stable release is always signed with an up-to-date and unexpired key.

To address ahf's second question: Yes, the new subkeys are always announced both on the first stable and alpha blogpost for releases which are signed with the new keys. In particular, for downstream projects like torbrowser-launcher the *alpha* blog posts are relevant here as they introduce new keys *months* before they reach the stable series. We test the new subkey during a bunch of alpha releases before it is used for stable, too.

For the third question: I don't know about a location for the (new) keys. I make sure that gpg --recv-keys is working before using the new key and am under the assumption that getting the key via any other web request would be failing, too, if the gpg command is failing. That said, I am fine if someone wants to put the Tor Browser signing keys fetched via gpg --recv-keys at some other place for easy download.

comment:4 Changed 10 months ago by gk

Resolution: not a bug
Status: newclosed

I am closing this bug as I am not sure what exactly we are supposed to be doing given comment:3. And, yes, if Trisquel is still shipping torbrowser-launcher for March 2016 there is not much we can do about potential breakage.

Feel free to reopen, or better, to file separate issues for concrete things the browser team should be doing.

Note: See TracTickets for help on using tickets.