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.

[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?

[Eveeifyeve]

Sorry I have been ignoring it for the past weeks, I've been working insanely hard at startups and haven't gotten the change to switch to buildMozillaMach. I will prioritise getting started to use buildMozillaMach as recommended by emilazy in this comment and I will not let this merge until upstream is stable as it is still in beta because it's a single developer that can't make promises like security on their website from before which caused 12 days of unreported vulnerabilities in the nix ecosystem and rolled back without notifying that it involves several CVE's ranging from high to low, for context read here as well as here, this pr is simply going to be blocked from being merged until it's stable, switched to buildMozillaMach and llvm closure size issue is figured out.

No hate to you @mauro-balades but it's just that nixpkgs has a very big security policy from @mweinelt (Maintainer of Firefox package in nixpkgs) to follow according, the fact you did leave it for 12 days when nixpkgs wasn't notified this reintroduces security vulnerabilities to mark it accordingly with meta.knownVulnerabilities so our users are aware, which caused this to be blocked till stable. There is also other factors to take into account but that was the main factor.

[Eveeifyeve]

An example of unstable in discord:

They have also removed the release on their website to hide the security practices 1.0.1-a.20, 1.0.1-a.21 & 1.0.1-a.22.

[mauro-balades]

Hmm, I don't remember removing those releases... But uhh, how is release from b3 to B4 a security issue? Even stable software has breaking updates that need fix

Edit: I remember now, there aren't release notes because of that one time they got backed out. But idk man, if you are going to keep me held because and alpha product was doing a ground breaking update AND wasn't using RC builds (which we now do) that's up to you, I stopped caring. At this point you are just forcing users to download third party packages to install zen, and I don't know what's worse

[JulesdeCube]

Hello,

Discaimer : I am not a maintainer I am just giving my thought on the situation

I understand the Security and maintenance concerne that @Eveeifyeve and emilazy have but I think that we can put zen at try.

I propose that we monitor zen for 4 months so we can see 3 full Firefox releases (I can do it if you want ) .

If we didn't found any security issue after this periode and that the llvm closure size issue is resolve we could consider that zen as "lean from it's mistake" and is safe to merge (when the mr is ready).

[mauro-balades]

Yeah well, im not going to stop people from using it. So ill be recommending https://github.com/0xc000022070/zen-browser-flake in the meantime

[Eveeifyeve]

This pr will still be able to be used in flakes via:

inputs = {
   zen-browser = "github:eveeifyeve/nixpkgs/zen-browser";
};

I will try to update this pr but can't guarantee it will be updated to latest.