New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] firefox-esr-52: remove, it's EOL around now #45787
Conversation
See the picture at https://www.mozilla.org/en-US/firefox/organizations/ The changes in common.nix are just no-rebuild simplifications, after the lowest supported version being bumped to 60.
👎
tor-browser's are based of 52. The ones based of 60 are still alphas.
|
|
I think we build torbrowser etc. from the Tor project's bundle. It doesn't use nixpkgs firefox derivation. |
We fetch its source from https://github.com/SLNOS/tor-browser, but I'd expect @oxij to know that much better than us 😕 |
Top-level `torbrowser` is `tor-browser-bundle-bin`, i.e. `patchelf`ed binary made by torproject (that attr needs to be moved to aliases to prevent confusion).
`firefoxPackages.tor-browser` is source-based build of the thing with the unbundling reverts maintained by SLNOS and with profile-dir-from-env patch of Nixpkgs, `tor-browser-bundle` top-level derivation then uses `firefoxPackages.tor-browser` to make a from-source built `tor-browser-bundle-bin` equivalent.
`firefoxPackages.tor-browser` is 52 based.
Building with OfBorg will fail either way, so I won't try to prove it that way, but looking at the changes I'm pretty sure `firefoxPackages.tor-browser` will be broken with this.
I'm also generally 👎 on dropping things to soon, older versions are sometimes useful for comparisons, and maintaining this one is not particularly expensive, it's only three optionals. I'm building those regularly, so I'll fix it the next time somebody breaks it again.
I'm 👍 on marking it insecure, though.
|
|
It doesn't build (due to this commit). I tried. Thanks Oxij for explaining. |
My main intention is to drop the Mozilla certainly claims 52.9 to be the last, though the current release probably isn't "insecure" yet, and there are hints that a really critical vulnerability might still entice them to release more 52.9.x versions. |
Looks like it fetches the complete source from SLNOS.
Yes, torproject doesn't distribute source tarballs and maintaining a single git repo is simpler than fetching git sources from torproject and then separately fetching patches from GitHub (also, SLNOS uses a custom `fetchFromGitHub` that compares tarballs produced by the normal `fetchFromGitHub` and the results of `fetchgit` (followed by git-archive and unpack to replicate what GitHub does) from several mirrors, including SLNOS own internal mirrors, just in case one of them ever decides to become evil or gets hacked, that would be harder to replicate with a tarball + patches strategy).
It's trivial to verify that there's nothing evil in that repo by adding a clone url from https://gitweb.torproject.org/tor-browser.git/ as a remote, fetching it, checking out the common parent, reverting the patches SLNOS changes claim to revert in the commit messages, and looking at the diffs. I do that myself on each update (a bit more efficiently, though, I did that once and now I just look at the diff between diffs), just in case SLNOS maintainer ever decides to become evil or gets hacked.
@vcunat
Personally, I vote for keeping 52, eventually marked insecure, as long as it's feasible to maintain the expression.
|
@oxij thanks for explaining. I'm fine with that, and thanks to SLNOS community for maintaining it. But I guess the difference between |
Yes, |
I keep Firefox 52 ESR around for a pre-WebExtensions version of EPUBReader… Of course, I can copy the deleted derivation, or install a binary release. |
OK, so how exactly are we going to do this? Suggestion:
|
Apparently 52 ESR is still offered for download, but I suppose that's just forgotten for now, with September 5 as a marked date in the roadmap... still, I expect on 18.03 we'll just let it live without any "warning". |
is LGTM. |
I propose closing this. |
So, now we might be good to drop 52, right? Including the icecat and tor variant, I suppose? |
We really shouldn't keep around old and insecure versions of packages, especially in sensitive applications like the Tor Browser. Things using insecure versions of firefox should be marked as insecure, if not moved into an overlay. If I'm not mistaken, this currently includes all
|
Opened #77452 for master. |
As mentioned there, I don't see why. If they are marked as vulnerable, then what is the problem, exactly?
There are offline-use extensions probably won't ever be ported to newer firefoxes (e.g. an editor for hOCR format produced by `tesseract`).
|
Let's keep the discussion in one place, at #77452. |
See the picture at https://www.mozilla.org/en-US/firefox/organizations/
The changes in common.nix are just no-rebuild simplifications, after the lowest supported version being bumped to 60.
Waiting for a couple days for feedback.