Opened 17 months ago

Last modified 3 months ago

#30479 new defect

Move away from using signed git tags to avoid rollback attacks? — at Initial Version

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-rbm, gitlab-tb-tor-browser-build
Cc: kevun, arma, boklm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


When using git repos we try to build from signed git tags whenever possible and make sure we check the signature being valid. It turns out, though, that keys might expire at some point making the signature verification fail from that point on. This is unfortunate for some of reasons: it might break building current Tor Browser versions (see #19737) and it might break verifying older releases which would be nice to have to be able to verify later on that everything went right.

We chose in #19737 to ignore expired keys in the sense that we treat a signature as valid as long as the verification succeeds (modulo the expiration problem). Now it has been argued that this could lead to rollback attacks in the sense that an attacker could modify a git repo in a way that the tag we want to use point to older code while still satisfying all of the git tag signing consttraints we have.

However, thinking a bit more the expiration problem is actually orthogonal as this could even happen with a properly signed tag which does not suffer from a signature done with an outdated key, but which is still not the current version. That means assuming you have three tags t1, t2, and t3 and t1 has a sig which is expired while t2 and t3 not, but only t3 contains the critical fix then with a git attacker in question it does not make a difference whether we fix the expiration date problem as they could easily make us use t1 *or* t2.

For fixing the expiration date problem there are some proposals with different trade-offs:

1) We could use signing keys that do not expire (see: If at all this is only helpful for our own keys but we use other project's git tags as well which might use expired signing keys.

2) We could use Peter Todd's OpenTimestamps tool ( That again might seem useful but we have the problem again that we use other project's keys which might not have those timestamps.

3) Even if we solved 1) and 2) magically we'd still have the problem above that an attacker can point to either t1 or t2. So a different approach would be to point to (signed) commits directly to avoid the problem that (signed) tags could point to anything.

So, should we switch to pinning cpmmits from now on? Or is there even a better solution available?

(Thanks to kevun and arma for input)

Child Tickets

Change History (0)

Note: See TracTickets for help on using tickets.