Changes between Initial Version and Version 1 of Ticket #30479


Ignore:
Timestamp:
May 11, 2019, 12:14:09 PM (4 months ago)
Author:
gk
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #30479 – Description

    initial v1  
    1 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.
     1When 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 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.
    22
    3 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.
     3In #19737 we chose 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 points to older code while still satisfying all of the git tag signing constraints we have.
    44
    5 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.
     5However, 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 a key that is expired now, but which is still not the current version. That means: assuming you have three tags t1, t2, and t3 and t1 has a signature which is expired while t2 and t3 don't, 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.
    66
    77For fixing the expiration date problem there are some proposals with different trade-offs:
     
    13133) 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.
    1414
    15 So, should we switch to pinning cpmmits from now on? Or is there even a better solution available?
     15So, should we switch to pinning commits from now on? Or is there even a better solution available?
    1616
    1717(Thanks to kevun and arma for input)