qt5.qtwebengine: Pin to GCC 14

[OPNA2608]

No longer receiving fixes, and known-insecure.

---

Closes #475938

I noticed that changes to stdenv weren't actually reaching into the build cus of the whole qtModule thing, so I'm not sure if the existing llvmPackages_19.stdenv change actually ever did anything… Should do something now, I guess?

AFAIU, there is a desire to not keep qt5 around for too much longer, so this temporary-permanent pin should hopefully not be an issue…

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[emilazy]

Looking at the remaining list of packages that pull this in at all – and the fact that some of them are just via generic Python Qt bindings that it can probably be dropped from, and other distros like Arch have dropped the package – I think it might be time to finally drop this. It’s coming up on a year’s worth of Chromium CVEs now…

[bjornfor]

Looking at the remaining list of packages that pull this in at all – and the fact that some of them are just via generic Python Qt bindings that it can probably be dropped from, and other distros like Arch have dropped the package – I think it might be time to finally drop this. It’s coming up on a year’s worth of Chromium CVEs now…

Can we get the list of packages that this would break first? (I know I have at least one package that depends on qt5.qtwebengine on my systems -- I'm not happy about it, but I'd be even less happy if I cannot use the software at all.)

[LordGrimmauld]

Relevant: #437521 removes the qt5 webengine dependency for python-qt, that should cover the majority of dependent packages.

[emilazy]

Can we get the list of packages that this would break first? (I know I have at least one package that depends on qt5.qtwebengine on my systems -- I'm not happy about it, but I'd be even less happy if I cannot use the software at all.)

It's in the rebuild report of this PR. I spot checked a few things and about half of them had solutions (just a binding that can be moved to Qt 6 or have WebEngine support dropped from, upstream rewrote on Rust/Tauri years ago but we're shipping a version from 2023) with the other half clearly never going to be fixed (notice in the upstream repo that it's not being maintained, or being replaced upstream with a rewrite). Arch also dropped it already. We can't keep this building forever and it's unlikely the things that can still be moved off it will do so spontaneously at this point since they don't have enough Nixpkgs maintenance to have done it in response to the knownVulnerabilities.

[bjornfor]

It's in the rebuild report of this PR.

Where? I don't see it.

[OPNA2608]

Where? I don't see it.

Under Eval Summary.

[bjornfor]

Where? I don't see it.

Under Eval Summary.

Thanks! First time I'm seeing that. I went there before but didn't notice I had to expand "Changed packages (59)". (I focused mostly on the top diagram, and tried to interact with the "Eval/report" block, but that's marked as skipped...)

[bjornfor]

Re: Arch dropping qt5-webengine: keshavbhatt/whatsie#275. This hurts users. (And for myself, losing whatsie on the desktop means even stronger dependency on my Android phone...)

[emilazy]

WhatsApp has a web client, right? I can’t really recommend using what looks like a project that has been unmaintained for over a year using an unmaintained Chromium fork with a year’s worth of exploits unfixed, especially one that processes untrusted content (messaging platforms are often vectors for exploits). https://wiki.archlinux.org/title/WhatsApp suggests there are many potential alternatives.

We certainly can’t maintain Qt 5 WebEngine (and Qt 5 in general) indefinitely for it, since it doesn’t look likely that upstream will ever move off it. Of course you can always use it from an old Nixpkgs commit, if you accept the risk; it’s unlikely any other vulnerabilities and issues that pile up in its dependency tree will be worse than what’s already there.

[bjornfor]

WhatsApp has a web client, right?

Good point, thanks!

I can’t really recommend using what looks like a project that has been unmaintained for over a year using an unmaintained Chromium fork with a year’s worth of exploits unfixed, especially one that processes untrusted content (messaging platforms are often vectors for exploits). https://wiki.archlinux.org/title/WhatsApp suggests there are many potential alternatives.

Of that list, few are packaged in nixpkgs. Some are forks of forks, some even listed as unmaintained. The first one I tested (zapzap) crashed at runtime (looks like a packaging bug). I also tried ferdium, which is packaged, but only via .deb file. And ferdium seems to require a "ferdium" account, not WhatsApp... I'll use the webapp then.

So that was one of 59(?) affected packages. What about the rest? (Another one I have interest in: 'eagle'.)

We certainly can’t maintain Qt 5 WebEngine (and Qt 5 in general) indefinitely for it, since it doesn’t look likely that upstream will ever move off it. Of course you can always use it from an old Nixpkgs commit, if you accept the risk; it’s unlikely any other vulnerabilities and issues that pile up in its dependency tree will be worse than what’s already there.

Forever is impossible, agreed, but we have a PR now to allow 59 software packages to work for (probably) 6 more months. And it requires opt-in to accept the security risk, so it's not like we recommend using this software.

I don't think we should recommend users to run old pinned nixpkgs.

[bjornfor]

whatsie[1] and eagle build and run with this, thanks!

[1] Use the web app instead if you can.

[emilazy]

So that was one of 59(?) affected packages. What about the rest? (Another one I have interest in: 'eagle'.

10 of the listed packages are just aliases for Qt WebEngine and Qt WebView themselves, 7 of them are the same packages duplicated across Python versions, 3 are aliases of packages both inside and outside the Python set. So we’re at 49 off the bat. From these, the ones I’ve spot‐checked are:

• python3Packages.python-qt – this is just a binding library from which we could likely disable WebEngine support, and which shouldn’t be counted on top of the packages that depend on it, which are:

  • python3Packages.{gepetto-gui,gepetto-viewer,gepetto-viewer-corba} – only optionally depends on PythonQt, and according to @nim65s who is involved upstream the functionality is not being used. These packages are also currently already broken due to osgqt, and from my understanding the software itself are in the process of being deprecated and moved away from upstream.
  • csound-qt – again an optional dependency for plugins, this time opt‐in and disabled by default. We could presumably either drop WebEngine from PythonQt or stop explicitly enabling PythonQt support in csound-qt and be fine; in this case, since the upcoming upstream release drops PythonQt support and migrates to Qt 6, disabling it seems like the clear solution.

  Accordingly, we just dropped this in python-qt: drop #480008.

• python3Packages.pyqt5-stubs – the same, except it’s also completely unused in-tree; trivially droppable.

• python3Packages.orange-widget-base – only used by the leaf package python3Packages.orange3, which isn’t listed in the report because it is broken with NumPy 2, and has therefore failed to evaluate since February. Even before that, it has failed to build the entire time we have been on Python 3.13, and last successfully built in December 2024. As far as Qt goes, upstream actually supports Qt 6 and the packaging could presumably be ported to it, but clearly this package has been broken for a long time and nobody is taking care of it.

• python3Packages.spyder – upstream supports Qt 6 from a quick check, so its maintainer can presumably migrate it. (That covers all the Python packages.)

• notepadqq – we are shipping a beta version from 2019, there has been a README warning about the package not being actively maintained since 2023, and this was strengthened in December to say that crashes have been reported with newer library versions. There’s little reason to expect the situation will ever get better for this package.

• globalprotect-openconnect – was rewritten in Rust with Tauri upstream, which had a stable release in February 2024. We are instead shipping a version from January 2023(!). Clearly resolvable, but also clearly not getting any maintenance attention in Nixpkgs – which is a bit concerning for a VPN client.

• stremio – we’re on a version from March 2024, although there have been a few upstream releases since. Upstream appear to have moved active development to a Rust rewrite currently in beta, and are actively distributing it via the FlatHub beta repository. It would make sense to package that as a replacement for the Qt 5 version if there is interest. This is the package that led to the linked issue report.

• whatsie – dormant upstream for a year, a very dangerous thing to run with such a vulnerable browser engine, and can be replaced by at least the web client (I didn’t assess the other clients listed on the Arch wiki in depth, so it’s possible there are other contemporary alternatives that could be packaged too).

• qutebrowser-qt5 – a browser for untrusted web content. Nobody should be using this – and as we have a qutebrowser using Qt 6, there’s no reason to.

• lomiri.morph-browser – as per qutebrowser-qt5, although it seems that upstream has optional Qt 6 support and they are actively working on improving it. Depending on the status here, we could either switch it to Qt 6 now, or restore the package once it’s sufficiently matured. AIUI, Lomiri is a fork of Canonical’s abandoned Unity 8/Ubuntu Touch stack, and has had trouble keeping up with Qt 6 in general.

• eagle – last upstream release in 2020. Autodesk announced in 2023 that they were discontinuing it in favour of Autodesk Fusion over the next several years. By June 2026 – around the release date of 26.05 – it will be completely out of support, licensing will no longer be active, and it will be unavailable for download. So clearly things are not going to change here, and our existing package will likely break in the next few months regardless. With that said, it pulls in qtwebengine specifically because it goes to some effort to devendor the bundled library dependencies – at a pinch, we could probably allow it to use its bundled versions and move meta.knownVulnerabilities down to it, though given the upstream support status I’m not sure it makes sense to keep this in the tree regardless.

So that’s 15 out of 49, divided into 3 library packages that shouldn’t be counted separately, 4 packages where the dependency is optional and trivially removable (3 of which are currently broken anyway), 2 packages where the latest upstream versions support Qt 6, 2 packages where upstream has abandoned Qt altogether, 3 packages abandoned upstream, and 1 browser that is an acute hazard to use for anything (but that is migrating to Qt 6 anyway).

The reason we marked Qt 5 WebEngine vulnerable rather than removing it outright was because it affected the stable release, and to to give time for some widely‐used packages that weren’t exposing it to untrusted web content time to migrate (e.g. Jellyfin); I’d say that has now happened. I haven’t assessed the remaining 34 packages in depth, of course, but I think this is more than sufficient effort to support my assumption that the vast majority of packages that will ever migrate off Qt 5 WebEngine have already done so, and the burden of proof is to demonstrate that holding off for another release cycle would make a difference.

Forever is impossible, agreed, but we have a PR now to allow 59 software packages to work for (probably) 6 more months. And it requires opt-in to accept the security risk, so it's not like we recommend using this software.

I don't think we should recommend users to run old pinned nixpkgs.

The Qt/KDE maintainers no longer wish to maintain Qt 5 in general and plan to drop it, so everything that uses Qt 5 WebEngine is already going to break at some point soon by default, and triaging bug reports and fix PRs takes up time from their other work in the interim. It’s also been the consistent policy of the security team and release managers in my experience that packages marked as vulnerable are pending removal, absent remediation of upstream or downstream security issues, once load-bearing users have been dealt with, and it’s a documented part of the release process to remove EOL packages that won’t be supported for the life of the release where possible.

I’m not saying people should run their entire systems on old Nixpkgs, of course – I’m talking about mixing in packages that require Qt 5 WebEngine from an older version after it’s removed. As you said, I certainly wouldn’t recommend it; nobody should be using anything depending on Qt 5 WebEngine at all unless they absolutely cannot avoid it and know that their specific use case mitigates the risk in some way. But even the oldest, most unmaintainable piece of broken software may have some use to someone; being able to access historical packages like that where relevant is a big strength of Nix.

The usual reason that you’re better off overriding a vulnerability warning on the current version rather than getting software from an older one is getting fixes for other parts of the dependency tree, but in this case we’re talking about a browser engine that has a year’s worth of unfixed vulnerabilities, including the kind that are actively exploited in the wild by zero days; that’s as bad as it can get already, so there’s no sense worrying about the rest of the dependency tree.

[LordGrimmauld]

Draft for qt5 webengine drop is up at #480196

Will need a bunch more work (basically fixing all eval errors, either by dropping or updating or disabling features, but an end is in sight.

[OPNA2608]

• lomiri.morph-browser – as per qutebrowser-qt5, although it seems that upstream has optional Qt 6 support and they are actively working on improving it. Depending on the status here, we could either switch it to Qt 6 now, or restore the package once it’s sufficiently matured. AIUI, Lomiri is a fork of Canonical’s abandoned Unity 8/Ubuntu Touch stack, and has had trouble keeping up with Qt 6 in general.

Lomiri is currently being ported to Qt6 upstream. I'm on the team that works on Qt6 porting, but I'm veeeeeeeeeeeeeery low on spoons rn, for toooooooo many reasons... I think Qt6 Morph already works on Debian though.

I have a draft PR that enables building parts of the DE for Qt6, including Morph Browser, but Morph segfaults while loading its main QML file, and I haven't found the energy to dig into that yet... #467662 (comment)

[bjornfor]

Ok, so good reasons for gettting rid of (qt5) qtwebengine, but can we please fix nixpkgs right now by merging this PR? The way I think a project should be managed is to minimize breakage for people, and if breakage is introduced, fix it ASAP.

[Majiir]

+1. I had to pull this patch in because it was blocking me from updating. (I use teamspeak3.) The GCC 14 -> 15 switch hasn't made qtwebengine and my system any less secure than it was before.