Move away from using signed git tags to avoid rollback attacks?

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 reasons: it might break building current Tor Browser versions (see #19737 (moved)) and it might break verifying older releases which would be nice to have to be able to verify later on that everything went right.

In #19737 (moved) 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.

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

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: https://blog.invisiblethings.org/keys/). 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 (https://petertodd.org/2016/opentimestamps-git-integration). 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 commits from now on? Or is there even a better solution available?

(Thanks to kevun and arma for input)