Change:
fteLibPath = makeLibraryPath [ stdenv.cc.cc gmp ]; # Upstream source <del> version = "8.5.4"; </del> <ins> version = "8.5.5"; </ins> lang = "en-US";

Discussion:
Description (Similar to , which seems outdated?) The 8.5.4 version of tor-browser-bundle-bin package does not build at current (). To Reproduce Steps to reproduce the behavior: Attempting to install the package fails: Expected behavior Package installs successfully. Additional context Viewing , versions 8.5.5, 8.5.6 and 9.0a6 are the only one accessible from that mirror. I'm not sure why the earlier released versions no longer are published. Metadata Maintainer information:
I expect that the Tor project does not distribute old versions of their software due to its security-critical nature. Also, because it is networking software, there are probably compatibility concerns. As for the GitHub repo, it's a mess and has not updated properly in a year, so it doesn't have releases later than 8.0.2.
That makes sense, however feels like a pain to have packages break when no changes are made to anything in the world.. I'd expect that with the same expressions, ideally identical build outputs would result. You mean Yeah, I noticed that and was confused until I noticed the other mirror ().. Do you think it would make sense to drop the repo as a mirror entirely?
True, although ultimately Nix can only provide identical outputs when the inputs are also identical, which is why we check the hashes. Normally, we take pains to ensure the inputs will be available, but in this specific case, I think it may be better to let the package break. We should ask someone at the Tor project for an opinion on that. Yeah, I think so.
Okay, I've sent a PR to drop the mirror:
The problem of disappearing source could be alleviated by re-enabling Hydra builds for tor-browser-bundle-bin; then source tarballs should be mirrored to
Well, their CI puts a version (currently ~15 day old 8.5.4) probably not helpful... that archive might help, though.
sounds good to me
I'm still concerned about the security impact. Would it be possible to at least warn the user if the release has to be fetched from the archive?
I think the best we can do is to actively maintain the package, like we have to do for other packages whose source does not disappear upon new releases (e.g., tor itself, firefox, linux). For known vulnerable versions, we can add insecure markings.

Not that my opinion counts for much but I was pondering; what if we a new package that used the archive in addition to what we have now and also be vigilant with updates. The failing builds of the existing one would be canaries that the archive package needs updating, in case of lack of vigilance. That way users can always have a tor-browser (even if slightly older), which is still better than no tor-browser. $0.02
Yeah, I guess ultimately there's not much we can do to protect users who don't update. The analogy to linux is pretty convincing. That's an interesting idea, but implementing it as a package doesn't seem quite the right way. I guess a warning from CI would be more appropriate, but I don't think we have any existing process for that.
I'm still having the same problem mentioned by Used same steps to reproduce, same error occurs. More info:
and for anyone else stumbling upon this issue (like I did). Why this happens: download URL for tor browser is hardcoded in nixpkgs. In unstable it's updated pretty frequently, but can get out of date for stable channels. And tor browser people aggresively remove their outdated releases (for good reasons). To fix this, I've created (my first) overlay : I just copied the most recent URLs and hash from (but you can use any version you like). Use this as an overlay (see also: ). In my case this means adding this to my main : And you should be able to use tor-browser.