Yeah, mentioning me and @joachifm before merging would have been nice. Also, for vulnerable software there's a `knownVulnerabilities` mechanism, so I'd say 👎 to removing this completely anyway. So, tl;dr: I'd say let's revert and mark those as vulnerable instead for now, while we work out the solution to the problems discussed below. The main problem there is that tor-browser 9.0 became kinda broken after they integrated tor-button and tor-launcher into the browser itself. Firstly, tor-launcher is not a `.gitsubmodule`, thus the fetching of sources is kinda broken if you want to build it with the launcher. Secondly, the usual unbundling patches from SLNOS do work and the newer versions of it do build, but building with `--disable-tor-launcher` produces a broken tor-browser (about:settings crashes). Which, with the problems outlined below, resulted in the SLNOS maintainer of tor-browser patches throw a bit of a fit and resign. Which gives us the current state. I've been fiddling with the code there to make `--disable-tor-launcher` work with some ugly patching around, and I even have a version that seems to work now (needs a couple more days of testing, though), but there are several problems. In the first place, the idea of `firefoxPackages.tor-browser` was to make an app conforming to the UNIX-way, and the upstream tor-browser is now an non-UNIX agglomeration of many things (e.g., it wants to start tor daemon by itself now, thus throwing away the usual separate-user isolation and etc, which, btw, uncomfortably reminds me of libpulse of PulseAudio, ugh). Thus, even if we are okay with carrying a rather ugly patch to make `firefoxPackages.tor-browser` with `--disable-tor-launcher` actually work (which, I'd say, is probably okay), and, possibly, another patch to tame the integrated tor-button so that it would not throw a fit when working without direct access to tor daemon (which does not seem to be a problem now, but that needs testing), we would probably still need a separate version for our `tor-browser-bundle`, which would now need to be reworked to integrate with integrated tor-launcher (which I did not manage to successfully build yet). So, in short, I can make fresh versions of `firefoxPackages.tor-browser` work in short order. But I can't make `tor-browser-bundle` work in short order, and I don't really want to spend time trying as `firefoxPackages.tor-browser` works for me. /cc @joachifm on the latter point, I guess

Are there any users of firefoxPackages.tor-browser other than yourself?

Outside of SLNOS, I assume @joachifm is one such user, but other than that I don't think we have means to answer that question unless each user explicitly confesses. Unless Hydra now collects some statistics I'm not aware of. In general, IMHO, firefoxPackages.tor-browser + uMatrix is the only sane web browser setup there currently is (reasonably secure, can reasonably resist fingerprinting, has proper origin isolation, can disable anything you want by default, including the newly Turing-complete CSS3 that can send results of computations to arbitrary servers via media queries, thus making it another arbitrary code interpreter in the browser, does not send stuff to any corporate servers, half the web MITMed by CloudFlare does not throw infinite Google CAPTCHAs at you, etc). I actually use it as my default browser, even when not using tor, because, IMHO, it's what firefox should have been. So, if there are no other users of it in NixOS, which I doubt, given it worked perfectly okay and was updated within a week of upstream release for the previous 2.5 years, I can only shake my head in pity and regret at lost opportunities.

You assume old `tor-browser`, my reasoning assumes `tor-browser` version 9.0.4, like in #77507.

IceCat takes literally two conditionals in `common.nix`, TorBrowser takes a bunch, but almost all of them are localized in `configureFlags` and `buildInputs`. Most of the burden there comes from different versions of the `firefox` itself, IceCat and TorBrowser burdens are uber-tiny compared to what they provide, IMHO. Anyway, see #77507.