Unable to install package due to insecure dependency refusing to evaluate

Help
1

Trying to install globalprotect, then globalprotect-openconnect and I see the same issue for both. It is related to qtwebengine-5.15.19. I’m using flakes on the unstable channel.

Below is the output:

error: Package ‘qtwebengine-5.15.19’ in /nix/store/7iyyc1gmzkq6kis6zsbzr7di08g4jvbh-source/pkgs/development/libraries/qt-5/modules/qtwebengine.nix:442 is marked as insecure, refusing to evaluate.


       Known issues:
        - qt5 qtwebengine is unmaintained upstream since april 2025.
       It is based on chromium 87.0.4280.144, and supposedly patched up to 135.0.7049.95 which is outdated.

       Security issues are frequently discovered in chromium.
       The following list of CVEs was fixed in the life cycle of chromium 138 and likely also affects qtwebengine:
       - CVE-2025-8879
       - CVE-2025-8880
       - CVE-2025-8901
       - CVE-2025-8881
       - CVE-2025-8882
       - CVE-2025-8576
       - CVE-2025-8577
       - CVE-2025-8578
       - CVE-2025-8579
       - CVE-2025-8580
       - CVE-2025-8581
       - CVE-2025-8582
       - CVE-2025-8583
       - CVE-2025-8292
       - CVE-2025-8010
       - CVE-2025-8011
       - CVE-2025-7656
       - CVE-2025-6558 (known to be exploited in the wild)
       - CVE-2025-7657
       - CVE-2025-6554
       - CVE-2025-6555
       - CVE-2025-6556
       - CVE-2025-6557

       The actual list of CVEs affecting qtwebengine is likely much longer,
       as this list is missing issues fixed in chromium 136/137 and even more
       issues are continuously discovered and lack upstream fixes in qtwebengine.


       You can install it anyway by allowing this package, using the
       following methods:

       a) To temporarily allow all insecure packages, you can use an environment
          variable for a single invocation of the nix tools:

            $ export NIXPKGS_ALLOW_INSECURE=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 add ‘qtwebengine-5.15.19’ to
          `nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
          like so:

            {
              nixpkgs.config.permittedInsecurePackages = [
                "qtwebengine-5.15.19"
              ];
            }

       c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
          ‘qtwebengine-5.15.19’ to `permittedInsecurePackages` in
          ~/.config/nixpkgs/config.nix, like so:

            {
              permittedInsecurePackages = [
                "qtwebengine-5.15.19"
              ];
            }

This github issue seems to be the closest and most recent relevant thing I could find: qt5.qtwebengine: mark vulnerable by LordGrimmauld · Pull Request #435067 · NixOS/nixpkgs · GitHub

Ideally, I would like to avoid installing it that version of qtwebenige, but I’m not sure how to go about fixing this issue. Any idea as to what my options are? or what is considered best practice in this scenario?

Thanks in advance!

1 Like
2

i think as long as the package build needs qtwebengine, there’s no easy way around it

i have run into similar stuff before (i think it was electron?), but since i really need that software for work, i had to override it with permittedInsecurePackages

hate to say it, but it’s just a notice, whether it’s actually insecure or not depends on the software itself and your usecase

1 Like
3

According to v2.0.0-beta1, globalprotect switched to rust+tauri. Since v2.4.0, they are using tauri v2, which no longer relies on libsoup2 (which is also vulnerable to different things). There does already exist a version 2.4.5.

The version in nixpkgs is wildly outdated (jan 2023), and the package desperately needs an update. Looking at the changes (rust and tauri, meaning webkitgtk instead of qtwebengine), this essentially means a rewrite of the package expression.

gpauth and gpclient are 2.x versions, but the gui package is missing because it apparently also became proprietary. I am personally not interested in touching that package, but it is no wonder such old packages will eventually rely on unmaintained and vulnerable technology.

1 Like
4

VPNs are a dime a dozen, you’ll fare much better using one that supports wireguard and setting that up with NetworkManager and the relatively standard wirrguard config files. VPN “apps” are universally abandonware that ultimately don’t do much more than NetworkManager behind the scenes, beyond some auth (that eventually collapses to openvpn/wireguard auth anyway) perhaps.

You might have no real option because of employer policies, of course, at which point you’ll have to either use insecure software to log into your VPN or you’ll have to figure out how to update the package.

2 Likes