I’ve being trying to add a package arweave that is flagged as insecure. Since I don’t won the package in question I added all the options available.
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 ‘openssl-1.1.1w’ to
`nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
like so:
{
nixpkgs.config.permittedInsecurePackages = [
"openssl-1.1.1w"
];
}
c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
‘openssl-1.1.1w’ to `permittedInsecurePackages` in
~/.config/nixpkgs/config.nix, like so:
{
permittedInsecurePackages = [
"openssl-1.1.1w"
];
}
Here is the flake.nix from the /etc/nixos:
{
description = "NixOS configuration";
inputs = {
nixpkgs.url = "github:nixos/nixpkgs";
# home-manager, used for managing user configuration
home-manager = {
url = "github:nix-community/home-manager";
# The `follows` keyword in inputs is used for inheritance.
# Here, `inputs.nixpkgs` of home-manager is kept consistent with
# the `inputs.nixpkgs` of the current flake,
# to avoid problems caused by different versions of nixpkgs.
inputs.nixpkgs.follows = "nixpkgs";
};
nix-ld.url = "github:Mic92/nix-ld";
nix-ld.inputs.nixpkgs.follows = "nixpkgs";
arweave.url = "github:ArweaveTeam/arweave";
nix-ld.inputs.nixpkgs.follows = "nixpkgs";
};
outputs = {nixpkgs, home-manager, nix-ld, arweave, ...}@inputs:
let
system = "x86_64-linux";
pkgs = import nixpkgs {
inherit system;
config.permittedInsecurePackages = [
"openssl-1.1.1w"
];
};
in {
nixosConfigurations.nixos = nixpkgs.lib.nixosSystem {
inherit system;
modules = [
nix-ld.nixosModules.nix-ld
arweave.nixosModules."x86_64-linux".arweave
./configuration.nix
# make home-manager as a module of nixos
# so that home-manager configuration will be deployed automatically when executing `nixos-rebuild switch`
home-manager.nixosModules.home-manager
{
home-manager.useGlobalPkgs = true;
home-manager.useUserPackages = true;
home-manager.users.vini = import ./home.nix;
}
];
};
};
}
Yes the unfree works, but seems that since is a package that I’m adding via flake the configuration for that particular pkg is not working, I’m not sure why.
What you mean by
If you set nixpkgs.pkgs the config will be ignored.
I think the issue here is that while you’ve correctly specified permittedInsecurePackages in the flake, there isn’t actually anything passing it into the nixosSystem call. As a result, the module system ends up creating it’s own Nixpkgs set, which doesn’t have the configuration applied that you specified in the flake.
To fix this, you want to specify the nixpkgs.pkgs option in one of the modules included in the system. Probably the easiest way to do this is to add the following into the attribute set you already have in modules:
nixpkgs.pkgs = pkgs;
That way, the system configuration knows that you want to use the version of pkgs that you configured with the permittedInsecurePackages options.
But I still get the message when I run sudo nixos-rebuild switch
error: Package ‘openssl-1.1.1w’ in /nix/store/4ab6vrcph07w6ra79bc04fy8bbcmb9r0-source/pkgs/development/libraries/openssl/default.nix:224 is marked as insecure, refusing to evaluate.
Apologies, I totally missed the nixpkgs.config bits in the configuration.nix - my bad That should have worked, however jumping into this arweave flake I think I see where the issue is. TL;DR - if you set inputs.arweave.inputs.nixpkgs.follows = "nixpkgs" in the flake, try and remove that - fingers crossed that resolves the issue.
For a more indepth explanation:
This flake provides the following NixOS module definition:
Of note here, is that the flake is defining it’s own pkgs set, and then using that to create the arweave derivation. It then throws that already created derivation into an overlay, completely ignoring your configurations Nixpkgs configuration as a result. IMO this is bad form on the flake authors part - the callPackage should be occuring here inside the overlay, not outside of it - that way, flake consumers can customize Nixpkgs config and have it apply to arweave.
Taking a look at the flake’s lockfile, it seems to have quite an old commit of Nixpkgs in there (~2 years old). I assume it’s old enough that openssl-1.1.1w wasn’t marked as insecure yet, and so if you leave the arweave flake to use it’s own nixpkgs input, and not make it use your flake’s version, that should be enough to get the build going.
Good spot however that aerweave is not built with an overlay, despite being added through an overlay, so we need to modify the configuration of the nixpkgs it is built with.
The easiest way would be to override the pkgsaerweave is built from, I suppose, but I’ve not tested this - unsure it will make stdenv.mkDerivation come from our pkgs:
environment.systemPackages = let
aerweave = pkgs.aerweave.override { inherit pkgs; }
in [
aerweave
];
Ultimately this is an upstream bug, though. Their project has not updated flake.lock in two years either, I’d ping them an issue.
I’d recommend you stick to adding the configuration via the NixOS module, by the way, and remove the nixpkgs.pkgs setting as well as the stuff you added in flake.nix.
This flake might not really be usable in its current state, sadly. Overriding the pkgs like I show will also fast-forward all dependencies 2 years, which will probably not go smoothly? We’ll likely have to override the pkgs from aerweave, but please try the above first.
Oh, whoops, sorry, skimmed past you suggesting to removefollows - that should indeed work as well, yeah. I also skimmed past the follows being there in the first place, and hence assumed the flake was just broken.
I clearly am not fully awake…
Edit: Wait, no, you’ve tried removing follows, I’m pretty sure upstream is just also broken.
That seems mostly pointed at usage with nix profile - OP mentions running nixos-rebuild switch, presumably with the --flake flag, so I’m not sure how applicable that is to this case. FWIW, I do a similar thing as I described earlier in my config (albeit a bit more convoluted - see defineSystem in particular), so I’m pretty confident that setting nixpkgs.pkgs in this case should be fine. nixpkgs.config would work too - both achieve the same thing ultimately.
Looking at the derivation, that should work, since that’s where they’re pulling beamPackages.rebar3Relx to create the derivation from (although looking at this, I’m not sure why they used callPackage here, since they’re not even making use of it… very strange code). Worth a shot, if pulling the follows doesn’t end up working.
It’s the same mechanisms, just applied subtly differently, mostly meant as some background reading since I thought you were saying we should addfollows. Sorry for the confusion!
Both work, using nixpkgs.pkgs shifts responsibility for evaluation into your hands and makes nixpkgs.config no longer work, though, so given @viniciuspalma was using nixpkgs.config for other things I think that just results in confusion.
Agreed! I’d understand if they insisted on pinning specific nixpkgs versions, but they’re clearly not maintaining this.
@TLATER & @srxl an immense thank you for you two. In the end I got it working on my current setup, seems that the flake update did the tricky without the follows attr.
Problem is that I did not achieve what I expected, since the executable isn’t in my PATH yet I suspect that how you both said the module isn’t updated regularly and not even the binary is copied by the end of the build process.
I’ll be following up by the Github Issue that I created and try to upgrade the libraries, but seems that isn’t going to be that easy.
That should have worked, however jumping into this arweave flake I think I see where the issue is. TL;DR - if you set 
I suspect that how you both said the module isn’t updated regularly and not even the binary is copied by the end of the build process.