• the release ISO's rely on firefox, so they would have to use the ESR version
• I think the pkgs/top-level/release.nix needs to be updated to rely on the firefox-esr as well

I have nothing against tracking ESR firefox by default, but by god, breaking the firefox derivation on stable by default is not something that should be done. All users with firefox installed should not be hit with a security error.

It seems to me that transitioning firefox to an alias for firefox-esr and introducing a new attribute for the up-to-date version would have less impact, while keeping to the spirit of this change.

How does firefox handle your profile when downgrading to the ESR (69 -> 68)? This is a question regardless of the chosen solution.

Last time I tried a firefox downgrade (as part of a system downgrade from unstable -> stable), it asked me to create a new profile, which was quite annoying. Maybe downgrading to ESR is better as firefox may support them? I'll test this later.

Downgrading from firefox 69 to 68 ESR appears to work seemlessly.

This should be mentioned in the release notes along with instructions on how to install firefox from the unstable channel.

This should be mentioned in the release notes along with instructions on how to install firefox from the unstable channel.

I think it's also important to mention someone could use the binary version of firefox. It's just the source based version of firefox in NixOS will only be esr on stable release. Don't really want someone to make the assumption, for whatever reason, NixOS will never have the latest firefox unless you use unstable.

I think the goal of this PR was to try and shock the team in to choosing a different option of how to manage firefox on 19.09?

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/firefox-on-19-09-could-be-marked-as-insecure-or-downgraded-to-esr-68/4577/1

I think it's also important to mention someone could use the binary version of firefox. It's just the source based version of firefox in NixOS will only be esr on stable release.

Wouldn't it be rather confusing to have firefox and firefox-bin be two different versions?

I think the goal of this PR was to try and shock the team in to choosing a different option of how to manage firefox on 19.09?

Kind of, yes.

We need to have the stable package discussion and what packages we are willing to maintain there and what updates are "allowed". The practice I proposed in the initial Firefox70 bump had been going on for a few releases without much pain. Now people consider it to be an issue (probably rightful?).

IMO this is way broader then just Firefox.

I also think that we do not have to be as strict on this as e.g. Debian as we have the proper tooling to do recompilation and thus can care a lot less about ABI stability. Of course it still must remain stable. But probably not stale.

If someone has the required energy and time we should eventually have a RFC on the topic of stable releases and version stability that we "guarantee".

Regarding the issue here: I'd really like RMs to chip on those topics regarding their release. We can provide them with all technical details regarding what will probably happen either way but they should be the people in charge of rolling the dice. Given that that happens in a reasonable amount of time and there is no need of rush…

Personally I liked having a current stable Firefox on stable NixOS despite being a lot of work. While the ESR releases are available they aren't really what regular users expect in my experience. I have mixed feeling about the binary releases. They are less tailored for our systems but might just run well enough. Running those on my machine effectively means executing some random binary that someone from Mozilla produced without any (ongoing) proof (on our part) that we can reproduce them from the source. Using the source built version is IMO preferable. The firefox-bin version is also unfree as per our packaging. That is yet another hoop users would have to jump through. That being said ESRs are probably fine for things like live images that just serve the purpose of installing NixOS…

The up- & downgrades should work fine within our Firefox releases. We are telling FFX to ignore / disable downgrade protections in our wrapper scripts.

Isn't having, say, sqlite-firefox package specifically for Firefox an option?

Isn't having, say, sqlite-firefox package specifically for Firefox an option?

We could probably just override the dependencies and fix them up to the right versions before passing them to Firefox. My fear here is that somebody touching the "real" expression might not be aware of the override practice we have for firefox and unintentionally breaks the build there.

That might not be as much of an issue for sqlite or even nss but it will likely be an issue with our rust infrastructure that we are consuming in the Firefox build. Just overriding things there will end up with very brittle expressions that might break on whenever rustc is updated. Also Firefox is usually fine with the latest version of dependencies. Whenever we pin them to something "known good" that might easily become outdated even thought we wouldn't really need a specific (old) version at that moment.

I certainly see specific packages/overrides as a way forward for the NixOS stable releases. On master we should just update the "real" expressions. This leads to a situation where we have to do some extra work during branch-off. Any thoughts?

The set that needs overriding is quite large, so I'm for dropping the maintenance burden, as people have plenty other options:

• ESR
• -bin EDIT: 🤔 or will that one require updated deps as well?
• install from unstable channel (the individual package; later this might be easier via flakes)

Of course, if someone steps up to promise maintaining all the backports (and will keep the quality), I don't think anyone will mind.

Of course, if someone steps up to promise maintaining all the backports (and will keep the quality), I don't think anyone will mind.

I am working on a version of that now. We / I might just have to do that for 19.09 and with 20.03 we should start with the non-esr removed by default.

I have merged that approach into staging-19.09: #71714

For 20.03 we should probably do this differently.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/firefox-crashes-when-opening-a-file-dialog-in-pantheon/5323/3