zen-browser: init at 1.0.2-b.4

[Eveeifyeve]

https://zen-browser.app/

Closes #327982

NOTE: This package takes quite a lot of resources to build. It took me an hour maybe two on my machine (3200g), This is not a package you want to compile yourself if you can avoid it.

If anyone wants to be added as a maintainer to this package, please leave a comment and I will add you.

Followup from PR #347222 that got reverted because of this comment: #347222 (comment) I want to make sure this pr is okay to go on nixpkgs the right way instead of reverting.

I will add myself as a maintainer once I have my darwin stuff sorted.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[Eveeifyeve]

I will need to fix the update script to update surfer and firefox.

[winterqt]

I want to make sure this pr is okay to go on nixpkgs the right way instead of reverting.

The PR had not only had technical issues, but project management issues inherent to upstream as well. As such, drafting until a consensus amongst committees/security/buildMozillaMach folks can be reached.

[Eveeifyeve]

@ofborg build zen-browser

[Eveeifyeve]

I want to make sure this pr is okay to go on nixpkgs the right way instead of reverting.

The PR had not only had technical issues, but project management issues inherent to upstream as well. As such, drafting until a consensus across committees/security/buildMozillaMach folks can be reached.

I mean it's in beta so there will be only small big changes but the Firefox version was rolled back because of half of the browser broke due to new apis in FF 133.

[Eveeifyeve]

@ofborg build zen-browser

This was the reason because It took two hours for a single build and my machine and I need to sleep.

[Eveeifyeve]

I will keep this in draft until it's fully stable.

[winterqt]

Looking at Surfer's code, it seems to be quite simple just to patch out the Git usages, even being able to contribute most (if not all) of these fixes upstream. Can we try that?

[Eveeifyeve]

Yeah I could look at doing that.

[Pandapip1]

There are a lot of git uses though: https://github.com/search?q=repo%3Azen-browser%2Fsurfer+%27git%27&type=code

I have NodeJS experience and could sumit a patch to use isomorphic-git instead to remove the git dependency if that would be helpful. Never mind, it doesn't support some git commands that are needed.

[winterqt]

There are a lot of git uses though

Most of them are not relevant to us, so we can ignore them. On a cursory glance, I count three that we'd want to patch:

• https://github.com/zen-browser/surfer/blob/ecd6b650f0234402976dde7e775d42aec6568406/src/commands/patches/git-patch.ts#L16-L18
• https://github.com/zen-browser/surfer/blob/ecd6b650f0234402976dde7e775d42aec6568406/src/commands/build.ts#L34
• https://github.com/zen-browser/surfer/blob/ecd6b650f0234402976dde7e775d42aec6568406/src/commands/download/addon.ts#L223-L230 (if Zen even uses addons)

[Eveeifyeve]

I've just worked on two patches that patch the addon one and the changeset in build. But I am having a bit of trouble of patching the git patch one as that uses the patches from zen browser and applies it directly to the engine.

[Eveeifyeve]

Unless a. use IFD which is against nixpkgs or b. include every patch in diretory. it turns out that this is not IFD if it was it would ofborg would eval error + gh actions.

[Eveeifyeve]

Working on darwin support, but a lot of libraries used that are linux based, is there an easier route of finding out what is using a linux thing directly.

[winterqt]

You would need to provide an example of a library in question, the error you run into, and why you think it's needed on Darwin.

[Pandapip1]

Working on darwin support, but a lot of libraries used that are linux based, is there an easier route of finding out what is using a linux thing directly.

You could run readelf -d </path/to/binary>

[Eveeifyeve]

Working on darwin support, but a lot of libraries used that are linux based, is there an easier route of finding out what is using a linux thing directly.

You could run readelf -d </path/to/binary>

But I can't build on my linux as it's not powerful enough, but I can with my darwin so I don't know what is using what.
And I keep getting these errors:

❯ nix build .#zen-browser
warning: ignoring the client-specified setting 'auto-optimise-store', because it is a restricted setting and you are not a trusted user
warning: ignoring the client-specified setting 'auto-optimise-store', because it is a restricted setting and you are not a trusted user
error:
       … while calling the 'derivationStrict' builtin
         at <nix/derivation-internal.nix>:34:12:
           33|
           34|   strict = derivationStrict drvAttrs;
             |            ^
           35|

       … while evaluating derivation 'zen-browser-1.0.2-b.0'
         whose name attribute is located at /nix/store/wy2ya7b9lbz5rjd272ncd9nkqqgk90xd-source/pkgs/stdenv/generic/make-derivation.nix:336:7

       … while evaluating attribute 'buildCommand' of derivation 'zen-browser-1.0.2-b.0'
         at /nix/store/wy2ya7b9lbz5rjd272ncd9nkqqgk90xd-source/pkgs/applications/networking/browsers/firefox/wrapper.nix:247:7:
          246|
          247|       buildCommand = ''
             |       ^
          248|         if [ ! -x "${browser}/bin/${applicationName}" ]

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: Package ‘systemd-minimal-libs-256.7’ in /nix/store/wy2ya7b9lbz5rjd272ncd9nkqqgk90xd-source/pkgs/os-specific/linux/systemd/default.nix:805 is not available on the requested hostPlatform:
         hostPlatform.config = "aarch64-apple-darwin"
         package.meta.platforms = [
           "aarch64-linux"
           "armv5tel-linux"
           "armv6l-linux"
           "armv7a-linux"
           "armv7l-linux"
           "i686-linux"
           "x86_64-linux"
           "loongarch64-linux"
           "m68k-linux"
           "mips-linux"
           "mips64-linux"
           "mips64el-linux"
           "mipsel-linux"
           "powerpc64-linux"
           "powerpc64le-linux"
           "riscv32-linux"
           "riscv64-linux"
           "s390-linux"
           "s390x-linux"
         ]
         package.meta.badPlatforms = [
           {
             isStatic = true;
             parsed = { };
           }
         ]
       , refusing to evaluate.

       a) To temporarily allow packages that are unsupported for this system, you can use an environment variable
          for a single invocation of the nix tools.

            $ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1

          Note: When using `nix shell`, `nix build`, `nix develop`, etc with a flake,
                then pass `--impure` in order to allow use of environment variables.

       b) For `nixos-rebuild` you can set
         { nixpkgs.config.allowUnsupportedSystem = true; }
       in configuration.nix to override this.

       c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
         { allowUnsupportedSystem = true; }
       to ~/.config/nixpkgs/config.nix.

[PerchunPak]

And I keep getting these errors

You could try nix eval .#zen-browser -vvv to find where this error happens

[emilazy]

We’ve had repeated problems in the past with under‐resourced browser forks failing to protect NixOS users from vulnerabilities. When concerns about how readily Zen’s release process can keep up with upstream security fixes were raised in the previous PR, the response was that they have been doing a good job so far. That may have been true at the time, but Zen ended up shipping a known‐vulnerable version for 12 days. Compare that to the rule of thumb set by Firefox/buildMozillaMach maintainer @mweinelt, that downstream forks should ship upstream security fixes within 72 hours at most and preferably 48, and I think you’ll see that this is a significant issue that merely releasing a new version almost two weeks later does not address. They knew their current version was vulnerable but put out no warning or advisory about rolling back to it and do not seem to have been in any hurry to make a release addressing it. That’s just irresponsible for a browser intended for wide public use.

Given this major security failure, our default position should be to not ship this browser. We currently have no reason to expect they will reliably ship timely updates in the future. It’s entirely likely that they run into issues with another Firefox update and quietly roll back again, causing a routine Nixpkgs package update to expose users to security issues. Given their separate version scheme, it’s possible nobody would even notice that it happened and we would fail to respond appropriately. Of course, it’s a project in the alpha stages and their release engineering and security practices may not yet be equipped to keep up with Mozilla, but that’s a good reason for us to not expose users to this risk, and they haven’t clearly communicated that people can’t expect Zen to be secure – in fact, until a recent redesign, their website claimed that it’s “Always up to date”, that “Zen Browser is built on top of Firefox, ensuring it always stays up to date with the latest features, security patches, and performance improvements”, and that they have “Automated Releases to ensure security”. Clearly, there’s a gap between marketing and reality here.

For it to be acceptable for us to ship another Firefox fork that imposes burden on the security team, their development and release processes would have to mature substantially. That might mean a stable release accompanied by an explicit commitment to more reliable security updates than previously, or a postmortem about how they ended up rolling back to a vulnerable version for this long without any advisory, but given their handling of this situation I don’t think we can commit to shipping this package at present. I think the responsible thing is to impose a moratorium and maintain packages out of tree until there’s a clear signal that we can expect things to be different going forward; a stable release by itself doesn’t mean that much unless it is accompanied by an explicit change in priorities around security.

Some other secondary concerns I have with the current state of this PR:

• This is substantially based on the work in zen-browser: init at 1.0.1-a.22 #347222, but the commit metadata contains no credit to @matthewpi. Either the Git commit author should be restored or a Co-authored-by: trailer should be added to give appropriate credit and avoid a licence violation.

• This duplicates code from buildMozillaMach, some of it incorrect as a result (e.g. the LTO stuff looks wrong). It would be best for us to apply their patchset on top of the pristine Firefox source ourselves and then use the standard buildMozillaMach rather than relying on their own build tool.

• The LLVM closure stuff should of course be addressed.

However, I want to be clear that I think the upstream security posture is the overriding concern here and that solving these secondary issues alone would not be sufficient to merge this PR.

[mauro-balades]

Zen ended up shipping a known‐vulnerable version for 12 days

Where are you getting this from? It was literally released on the same day

There's a bit of time-zone issues here. Maybe you are confusing zen with waterfox?

[zoriya]

I think this is about the a.20 that got rolled back in a.21. The FF version only got updated for the beta release ~two weeks after.

[mauro-balades]

Hm, there wasn't any major security issues while in 21. There where some medium security issues, but those updates really did break up how firefox handles a lot of their UI components and while transitioning from alpha -> beta. So it's reasonable it may had taken a bit more of time, but now we have developed a more efficient and stable way of handling these firefox updates. But I woudnt call it a "major security failure", specially knowing we are reaching to the stable versions soon

[emilazy]

There were multiple known security vulnerabilities in Firefox 133 at the point Zen rolled back to 132 and remained there for almost two weeks, one of which was high severity. As discussed in #347222, that just falls below the standards we consider acceptable for browser forks, and which the ones we ship like LibreWolf have managed to keep up with so far. I can understand if Zen doesn’t have the resources to keep up with new upstream versions in a timely fashion, but downstream forks that can’t get releases out within ~3 days of upstream security fixes are not something we can ship to users in good conscience.

The question is not so much which security vulnerabilities were being shipped to end users in practice – although clearly there was at least one that Mozilla considered to be serious – but the fact that even if there had been extremely serious issues it doesn’t seem like Zen would have been equipped to protect their users in that period. At a minimum I think the version that rolled back to the Firefox version with known vulnerabilities should have contained a prominent notice in the release notes that it was known to be insecure and linked to the upstream advisories. That way users and downstream distributors would at least be aware of that (and we could have e.g. marked it with knownVulnerabilities on our end to warn our own users).

[Eveeifyeve]

• This is substantially based on the work in zen-browser: init at 1.0.1-a.22 #347222, but the commit metadata contains no credit to @matthewpi. Either the Git commit author should be restored or a Co-authored-by: trailer should be added to give appropriate credit and avoid a licence violation.

@matthewpi is now credited .

• This duplicates code from buildMozillaMach, some of it incorrect as a result (e.g. the LTO stuff looks wrong). It would be best for us to apply their patchset on top of the pristine Firefox source ourselves and then use the standard buildMozillaMach rather than relying on their own build tool.

I mean that could work but the problem I run into is using an update script to update the browser in less than 72hrs.
But also another problem is fetching where the patches are could get complex and if paths change then yeah it could break.

• The LLVM closure stuff should of course be addressed.

I haven't found the root cause because I am working on getting darwin builds working.

However, I want to be clear that I think the upstream security posture is the overriding concern here and that solving these secondary issues alone would not be sufficient to merge this PR.

Just to note I am note I am keeping this draft until stable or they improve their security but most likely stable would be better as hopefully security improves I have let @mr-cheff know in discord about this and to reflect on this.

[mauro-balades]

Wait, does brave, vivaldi, opera, etc release chromium updates without properly testing it for at least a week? Such big updates can break so many things, they must have insane developers

[networkException]

Wait, does brave, vivaldi, opera, etc release chromium updates without properly testing it for at least a week? Such big updates can break so many things, they must have insane developers

They have normal developers doing testing on beta versions, incremental rollouts, backporting of security patches and rollbacks as their day to day job.

[emilazy]

Yes, the only real way to keep up with browser vendors and not put users at risk is to develop and test on development versions significantly in advance of them being released, so that you can cut a well‐tested release in a timely fashion after upstream does. (And with Chromium I guess there’s also a larger ecosystem of third parties backporting security fixes to earlier versions, e.g. Qt. Firefox ESR gets similar support and would significantly reduce the frequency of churn, but I guess it wouldn’t be acceptable for Zen.)

[mauro-balades]

Oh, so they get their updates in advance? I might need to take a look into that, that sounds like a good thing to do

[mauro-balades]

Oh wow, this actually opened my eyes a lot. Ill be changing stable releases to RC, so I can test builds 1 week before actual release (https://archive.mozilla.org/pub/firefox/candidates/)

Thanks a lot! I coudnt had learned this if it wasnt for this convo

[emilazy]

Ideally you’d want to keep up to date with the upstream Mercurial (soon to be Git?) development version of Firefox and create release branches when they do, so that even by the time an upstream release candidate is cut you’ve already had time to adapt to the changes and get some testing of the result (say, by offering nightly builds to users).

[mauro-balades]

Thanks a lot! Ill look into it more in depth

[Eveeifyeve]

Ideally you’d want to keep up to date with the upstream Mercurial (soon to be Git?)

I heard about Firefox switching to git, is that still happen or not cause I heard at nov 2023 they were going to start switching in 6 months, but I don't know any progress has been done?

[TheGiraffe3]

What do the .patch files do?

[Eveeifyeve]

What do the .patch files do?

They are just code that applies in the PatchPhase which is useful for nix as some programs use stuff that nix does already but in the case for buildMozillaMach you would need to apply the patches that they already apply already. But you can read more about how patching works through the git reference manual.

[mauro-balades]

You can just set exoirt SURFER_COMPAT="arm64" at build time

[Eveeifyeve]

This is going to be migrated soon to buildMozillaMach as discussed with @emilazy in this comment and surfer is no longer going to be used.

[mauro-balades]

That's weird, you don't build zen the same way you build firefox. But I dont know anything about nix so don't listen to me. I do want to state we are moving from beta to release branches, so you may want to update that

[Eveeifyeve]

I do want to state we are moving from beta to release branches, so you may want to update that

I will update the source when the time that zen browser has a release tag for release as we use a tag system in src here

[dunklecat]

Seems like they're taking steps to the right direction, am I wrong?

Release notes for 1.6b
January 7, 2025

This new release includes more polishing changes and bug fixes. We are most excited about our new release schedule, we are now using Firefox's Release Candidates for twilight, meaning we can test out new Firefox versions before they are released to the public.
[...]

source: https://zen-browser.app/release-notes/

[Eveeifyeve]

Seems like they're taking steps to the right direction, am I wrong?

Release notes for 1.6b
January 7, 2025
This new release includes more polishing changes and bug fixes. We are most excited about our new release schedule, we are now using Firefox's Release Candidates for twilight, meaning we can test out new Firefox versions before they are released to the public.
[...]

source: https://zen-browser.app/release-notes/

But still doesn't make the fact they left it for 12 days instead of 48-72 hrs or less respondent as requested by the firefox/buildMozillaMach maintainer @mweinelt, read @emilazy comment above for more info

[Pandapip1]

But still doesn't make the fact they left it for 12 days instead of 48-72 hrs or less respondent as requested by the firefox/buildMozillaMach maintainer @mweinelt, read #363992 (review)

I don't fully agree: it's clear that the developer didn't know about keeping their patches up-to-date with the nightly builds, and it's also clear that once it was shown that releasing on top of an outdated Firefox was both unacceptable and avoidable, they took steps towards making sure it won't happen again. This seems to have been a learning experience for the zen-browser developer, and it shouldn't disqualify zen-browser from inclusion in nixpkgs, as long as the new process holds up. Whether it does remains to be seen.

[Eveeifyeve]

But still doesn't make the fact they left it for 12 days instead of 48-72 hrs or less respondent as requested by the firefox/buildMozillaMach maintainer @mweinelt, read #363992 (review)

I don't fully agree: it's clear that the developer didn't know about keeping their patches up-to-date with the nightly builds, and it's also clear that once it was shown that releasing on top of an outdated Firefox was both unacceptable and avoidable, they took steps towards making sure it won't happen again. This seems to have been a learning experience for the zen-browser developer, and it shouldn't disqualify zen-browser from inclusion in nixpkgs, as long as the new process holds up. Whether it does remains to be seen.

I think there is still a lot of work to do like moving to buildMozillaMach & llvm closure to be addressed, but the problem this did happen and I think just personally we shouldn’t ship until stable of the browser because there is still breaking changes and this could in theory happen again or something worse.

[mauro-balades]

But still doesn't make the fact they left it for 12 days instead of 48-72 hrs or less respondent as requested by the firefox/buildMozillaMach maintainer @mweinelt, read #363992 (review)

I don't fully agree: it's clear that the developer didn't know about keeping their patches up-to-date with the nightly builds, and it's also clear that once it was shown that releasing on top of an outdated Firefox was both unacceptable and avoidable, they took steps towards making sure it won't happen again. This seems to have been a learning experience for the zen-browser developer, and it shouldn't disqualify zen-browser from inclusion in nixpkgs, as long as the new process holds up. Whether it does remains to be seen.

It has definitively been a learning experience for me haha. I didn't know RC builds even existed before. Updating Firefox, getting it tested for one week and release on the same day is... so easy now. And all thanks to this thread!

Ill 100% keep maintaining updates like this. For example, twilight branch (https://github.com/zen-browser/desktop/actions/runs/12757747570) is already on Firefox 134.0.1! All im saying is, please give it another chance 🙏🏽, maybe keep an eye for the next 3 Firefox releases (they do one release per month) so I can truly prove myself?