electron_31-bin: mark as insecure because it's EOL, electron-source.electron_31: remove as it's EOL

[emilylange]

Previously:

• electron_30-bin: mark as insecure because it's EOL, electron-source.electron_30: remove as it's EOL #350549
• electron_29-bin: mark as insecure because it's EOL, electron-source.electron_29: remove as it's EOL #335850

electron_31 will be EOL in less than two weeks (2025-01-14).

https://www.electronjs.org/docs/latest/tutorial/electron-timelines (permalink)

This PR removes the source build on Linux for electron 31 and marks the binary variants for Darwin and Linux as insecure.
electron_31 will still be available for an undetermined while. Linux will simply use the binary package instead of the source build, just like Darwin.

After this PR has been merged, users will be able opt-into the EOL version of electron as outlined by this eval error message:

# nix-instantiate -A electron_31
error:
       … in the condition of the assert statement
         at ./lib/customisation.nix:417:9:
          416|       drvPath =
          417|         assert condition;
             |         ^
          418|         drv.drvPath;

       … while evaluating the attribute 'handled'
         at ./pkgs/stdenv/generic/check-meta.nix:507:7:
          506|       # or, alternatively, just output a warning message.
          507|       handled =
             |       ^
          508|         (

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

       error: Package ‘electron-31.7.6’ in ./pkgs/development/tools/electron/binary/generic.nix:37 is marked as insecure, refusing to evaluate.


       Known issues:
        - Electron version 31.7.6 is EOL

       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 ‘electron-31.7.6’ to
          `nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
          like so:

            {
              nixpkgs.config.permittedInsecurePackages = [
                "electron-31.7.6"
              ];
            }

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

            {
              permittedInsecurePackages = [
                "electron-31.7.6"
              ];
            }

The following packages are affected by this. Note that those package will continue to work, but users will be presented with the eval error above and have to opt-in.
If you are pinged as one of the maintainers of such package, you can do one of the following:

1. Check if upstream supports a newer electron version and open a PR in nixpkgs to use that instead OR
2. Try using a newer electron version than upstream suggests and if that turns out to be stable, open a PR in nixpkgs to use that instead OR
3. Do nothing in nixpkgs, and maybe make upstream aware that their electron version is EOL.

• feishin (@onny, @jlbribeiro)
• heroic (@aidalgol) (heroic: update pinned electron version #370785)
• pocket-casts (@yayayayaka) (pocket-casts: update electron pin; move to pkgs/by-name/ #372095)
• webcord-vencord (@FlafyDev, @NotAShelf)
• zap-chip (@symphorien)

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.

[aidalgol]

Implemented option 2 for heroic in #370785.

[onny]

Feishin upstream issue jeffvli/feishin#879

[symphorien]

For zap let's do option 3. I notified upstream of the issue, but nixpkgs only needs the non-gui version of zap, which will still build. Thank you for the heads up, though.

[NotAShelf]

I'll look a take at webcord-vencord shortly.

[yayayayaka]

Thanks for the ping! Opened #372095 and notified upstream about the upcoming EOL date.

[emilylange]

Alright then, the electron_31 is now officially EOL.

I rebased this PR to resolve the merge conflict and also included a final 31.7.6 -> 31.7.7 bump for -bin and -chromedriver only.

https://github.com/electron/electron/releases/tag/v31.7.7

I intend to merge and backport this in a few hours or so.

The remaining and thus affected consumers of electron_31 are feishin, webcord-vencord and zap-chip-gui as per:

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 370758

---

x86_64-linux

⏩ 5 packages marked as broken and skipped:

• electron_31
• electron_31-bin
• feishin
• webcord-vencord
• zap-chip-gui

✅ 1 package built:

• electron-chromedriver_31

Note that as outlined in the opening PR comment, users of those packages will be presented with an eval error detailing how to opt-in.

PS: We should probably make electron-chromedriver inherit the version range for EOL (or any meta.knownVulnerabilities really) from electron in the future.

[NotAShelf]

I'm not sure why webcord-vencord is broken, it has been updated and tested.

[gepbird]

I'm not sure why webcord-vencord is broken, it has been updated and tested.

It's still pinned to electron_31:

nixpkgs/pkgs/top-level/all-packages.nix

Line 15725 in ae2fb9f

webcord-vencord = callPackage ../by-name/we/webcord-vencord/package.nix { electron = electron_31; };

Only webcord was updated, not webcord-vencord

[emilylange]

I'm not sure why webcord-vencord is broken, it has been updated and tested.

nixpkgs/pkgs/top-level/all-packages.nix

Lines 15723 to 15725 in ae2fb9f

	webcord = callPackage ../by-name/we/webcord/package.nix { electron = electron; };
	webcord-vencord = callPackage ../by-name/we/webcord-vencord/package.nix { electron = electron_31; };

webcord uses electron, webcord-vencord uses electron_31.

Also, you don't want to set electron = electron (as done for webcord).
The override is both redundant (electron is already electron) and risky (because electron will be electron_34 instead of electron_33 very soon).

Both should be electron = electron_33.