When I try to rebuild my system I get the following warning:
error: Package ‘electron-13.6.9’ in /nix/store/0pypqlnsmw5k1bkh2njpiyrdp7kiqymn-source/pkgs/development/tools/electron/generic.nix:26 is marked as insecure, refusing to evalua
I found out that the source is the Obsidian package however I’m using already the version from unstable so that solution in: Python 2 package Pillow is marked as insecure isn’t possible for me.
What would be the usual procedure in such a case?
While evaluating the attribute 'installPhase' of the derivation 'obsidian-0.13.23
I’d still suggest finding out why this is insecure, rather than just blindly accepting it, and perhaps fixing whatever is causing it to be marked as such (which may be as simple as resolving a mismatch between user and root channels).
if your install the package from your flake, you will need to do nix flake update to advance the flake.lock file to the head of the repo’s you ‘follow’,
if you using old tooling like nix-shell , these still use channels, there is a way to unify the system flake to update the channels for the so the old tooling and new tooling pull from the same nixpkgs.
@NobbZ has a piece of code that can do this, and could probably explain it a lot better.
It sets the nixpkgs path to the input flake, which makes anything that imports <nixpkgs> refer to the system flake, and unbreaks a lot of these things. If you do that, make sure you’ve removed any channels you used before starting to use flakes, so you don’t accidentally use the channels anymore - I’d suggest that in general.
The bit after that also sets the nixpkgs registry entry to the input, which makes commands like nix shell not download the newest nixpkgs-unstable every time (huge usability plus, I’d love to see flakes do this by default somehow one day).
It’s not quite the same, as your version changes the NIX_PATH environment variable and is therefore only active for processes that have started after the change, unless they inherit still old values from their parents.
I have my NIX_PATH pointing to fixed locations in the filesystem and change those symlinks targets on a rebuild.
I do use tempfiled to do so, which is probably overkill and etc.* hirarchy would be sufficient as well…
tlater ~ $ NIXPKGS_ALLOW_UNFREE=1 nix shell --impure github:NixOS/nixpkgs/nixpkgs-unstable#obsidian
error: Package ‘electron-13.6.9’ in /nix/store/lgma05szq43zgqnjmzilahsd52il3phg-source/pkgs/development/tools/electron/generic.nix:26 is marked as insecure, refusing to evaluate.
- Electron version 13.6.9 is EOL
You can install it anyway by allowing this package, using the
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: For `nix shell`, `nix build`, `nix develop` or any other Nix 2.4+
(Flake) command, `--impure` must be passed in order to read this
b) for `nixos-rebuild` you can add ‘electron-13.6.9’ to
`nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
nixpkgs.config.permittedInsecurePackages = [
c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
‘electron-13.6.9’ to `permittedInsecurePackages` in
~/.config/nixpkgs/config.nix, like so:
permittedInsecurePackages = [
(use '--show-trace' to show detailed location information)
Incidentally, that command lists all the ways you can work around this without fixing the problem.
I’m personally at a loss as for why the package is refusing to install, it may be a bug in the version-check function? You could try overriding the version of electron obsidian uses, test out the version check function in a nix repl, or maybe just concede and mark the package as usable despite insecure. I’d love to see a fix upstream though, if you can figure one out, or I may try later tonight
Who knows what caching magic resulted in this confusion, you seem to simply have tried updating at the worst possible time; using the insecure version for the minute is probably fine, if you wait a couple of days it will probably be resolved, or you could even attempt a patch for this yourself.
Good to know thank you.
I thought about opening an issue about it but I don’t really know what the guidelines for that are and how quick things like this usually get discovered.
I’ll go with the insecure variant for the moment, if it takes too long I probably try to overwrite the Electron package.