[Feature request] Sign and time-limit validity of update metadata

At the moment, metadata used by Tor Browser's updater (such as is available from https://aus1.torproject.org/torbrowser/update_3/release/download-linux-x86_64.json) is unsigned and contains no "Valid-Until" field. This means that an attacker capable of MITM'ing the connection between a user's device and The Tor Project's servers could in theory perform a rollback or infinite freeze attack, by either making the metadata point to an earlier, vulnerable version of Tor Browser, or by simply "freezing" the metadata in time from the user's perspective by never allowing updated versions of the file to be served (thus meaning any newly discovered vulns in the user's browser will not be patched).

In theory, TLS should usually defend against this kind of attack to some extent. But TLS is rather flimsy in a lot of ways; there are many environments in which users are intentionally subjected to TLS MITM measures via a root certificate, certificate authorities can adopt dangerous security practices (like Entrust) or be under reasonable suspicion of being malicious (TrustCor), vulns can be used to downgrade connections to an older, unsafe TLS version, etc. Just because TLS is enough for most users doesn't mean it will work well for everyone or work well all the time.

The Whonix project (which I contribute to) currently uses a script known as "update-torbrowser" (part of Kicksecure's tb-updater project at https://github.com/Kicksecure/tb-updater) that attempts to work around these issues by rigorously validating downloaded metadata, checking the provided browser version against a hardcoded known-good version, allowing users to manually verify that the binaries they are about to download have the version number they expect, etc. This works, but it's extremely complicated, requires a lot of user interaction in the event we (Whonix) don't update our hardcoded known-good version very quickly, and causes some user annoyance due to (slightly) delayed automatic updates. (https://github.com/QubesOS/qubes-issues/issues/9983 has some discussion about this.) Arguably this could even be considered a security issue, since even though the version lag isn't large, it's present, and the longer people use an outdated Tor Browser version, the worse the consequences could be.

With signed browser metadata, we could avoid all of this by simply downloading the metadata, downloading the signing key, verifying the metadata's authenticity, and checking a "Valid-Until" field to make sure we're not subject to a rollback or infinite freeze attack. With that done, update-torbrowser would then be sure that the info it had was authentic and reasonably up-to-date, and could trust whatever Tor Browser version number was specified in the metadata without having to have it hardcoded. This would allow new versions of Tor Browser to be installed automatically in a secure fashion with zero (or at least minimal) user interaction, and would probably allow us to simplify our code somewhat.

(Note that I'm filing this using Anon-Ticket, but only because I expect my request for a Gitlab account (with username arraybolt3) to take a while to process.)