On 19.09 the latest version of Firefox is currently 69. Version 70 has been released, however, it requires a newer version of a core library, sqlite. In stable releases we typically do not update versions of packages. The question is now how to proceed with this, for this case, but also for in the future.
Please have a look at [19.09] firefox: mark as insecure and remove myself as maintainer by andir · Pull Request #72126 · NixOS/nixpkgs · GitHub.
We do have, as part of previous discussions about backports (don’t have the link handy and the internet here is bad), a rule about that. Paraphrased:
Backporting new versions is allowed (and preferred) in these cases:
Browsers are of the first case, new versions will receive security updates, and browsers are the main chunk of exposure to security issues for users. Furthermore this is also a concern of usability, it would make using NixOS an annoyance for users that don’t setup a mixed system with multiple channels.
Browsers could also be of the second case, with shiny new features always getting added, but in reality these are more about software like “social” software, like service-driven chat (e.g. discord, slack), or for entirely service-driven software, like entertainment software (e.g. spotify).
Though, we should not upgrade sqlite wholesale on stable. Probably this requires an sqlite used by Firefox. I figure that on unstable that new sqlite has not been added under an attribute sqlite_x_y, right? If so then I’m not sure about the best way to add this to stable, while keeping sqlite to the current version. Though, I figure that, at the very worst, something like the following would be fine.
firefox = callPackage .../firefox {
sqlite = callPackage .../sqlite/x_y.nix;
};
The only drawback I see is that we don’t expose that new sqlite variant to the outside… But that’s the point, we do not want to expose that new sqlite variant to the outside.
Another valid approach would be to stick to the latest ESR release, right? Security patches should be provide for ESR releases IIRC. This could make life easier for everyone at the cost of not having the newest Firefox available.
But since there will be a new NixOS version out every half a year, we won’t be lacking behind that much anyway. So this would be my preferred option.
Another valid approach would be to stick to the latest ESR release,
right? Security patches should be provide for ESR releases IIRC. This
could make life easier for everyone at the cost of not having the
newest Firefox available.
Security patches absolutely will be provided – that’s what the ESR is
for!
I think this is the way forward. Security patches are the justification
usually given for updating browsers in stable, and if we stick to an ESR
that’s taken care of without the pain of trying to do partial upgrades.
This is similar to what we do for the kernel as of 19.09.
It’s a bit late to do anything about it for 19.09, so we’ll have to come
up with some other solution there, but for 20.03 I think we should just
remove non-ESR Firefox after branch-off, like we now do with Linux.
Latest Firefox is always available from unstable if somebody really does
need features less than six months old for some reason.
I know this may sound like a pure vanity argument, but there’s for sure a large part of the firefox userbase that might find NixOS of a lesser taste simply out of the fact that NixOS stable releases will never have latest firefox. I think it’s a unique challenge for NixOS to be able to do able to deliver this. I personally find having to pull software in from unstable taxing on a users machine, and what’s the pathway to even formally support this? I know it could be a lot more work to convert firefox to vendored after branch off, but I think that’s just one feat that Nix makes more convenient than trying to do this conventionally elsewhere. And to proclaim that doesn’t really mean much until someone wants to put in the work do this, but it’s certainly an option.
Apart from ESR, there’s always the option of pulling the whole Firefox closure from unstable, and maybe the latest -bin variant will keep working as well. As for how to make this better user-accessible, I think there are more options, perhaps via flakes in future.
Why should Firefox in particular be kept up to date, in contrast with
every other package in our stable distribution? I think this could be a
dangerous road to go down, and could lead to a maintenance nightmare –
the same justification could be applied to any other package.
We already have a good path for running stable and pulling specific
packages from unstable. I’m not sure what you mean by “formally
support”, but I’ve never seen anything to suggest that fetching closures
from unstable shouldn’t be supported – in fact the guarantees of Nix
mean that it should always work, short of something like a kernel
incompatibility. If it’s not documented well, that can be improved. If
it’s not elegant, well, there are ideas like Flakes that will improve
the flow.
For all the reasons I mentioned, software delivery vanity. This has already been the status quo, delivering the latest firefox to stable users, and it’s not an uncommon practice for many other distros. Even LTS ubuntu can provide this to their users. And I’d honestly be personally embarrassed if we had to do this, we release every 6 months.
All my points were why we should have latest firefox available to users on stable channels in the most convenient way, which is not pulling in different channels.
As for it being justified for other packages, I don’t think I have a response to that. I essentially meant there should be a no change of latest firefox being available. This exception is already being made for certain packages that fit the criteria @samueldr mentioned.
I’m also not sure if you’re aware about version mismatches with applications on stable. I’ve received lots of reports of things being broken, rendering issues, mismatched glibc crashes, gdk pibuf loader mismatches Programs using gdk_pixbuf 2.38 crash with 2.36 loaders from system · Issue #54278 · NixOS/nixpkgs · GitHub. Even woes with wrapGAppsHook just makes me discourage users from using applications from unstable entirely. So it could be that we couldn’t guarantee an unstable firefox on stable, which means it won’t be available at all outside the binary package. Mixing channels is less usable.
Hi, I’ll be short and to the point, which might look like I’m negative or combative, but this is only a list of facts about the current workflow.
As shown by my previously aborted RFCs about a dedicated backport team, there is already a (though not upstreamly) documented process the Nixpkgs community has been following since at least early January 2017.
Since this predates RFCs, there is no RFC for the process. The aborted RFC was more about codifying a workflow and tooling around the existing criteria.
Now I’ll be blunt. If there is a desire to change the process, it has to go through the RFC process.
Though, I will concede that the fact that this information was passed around via word-of-mouth, rather than included into the Nixpkgs manual is not great. Though, it is precedent about the way it has been happening since at least early 2017.