Correct, but you can use --override-input nixpkgs <url>.
Still, there’s no reason to rely on github, since there’s lockable tarballs, i.e.
inputs.nixpkgs.url = "https://channels.nixos.org/nixos-unstable/nixexprs.tar.zst";
Switch out nixos-unstable for the desired channel.
It depends, nix only fetches inputs as required (either by evaluation or as part of a flake update) and only if the input is not already in the nix store or nix doesn’t know the content’s hash.
So after a rebuild, the flake is still buildable even if GitHub goes offline, at least until a gc.
Removing unpopular packages is being brought up every now and then but it does not bring security benefits:
Packages only affect people that install it. A vulnerable package nobody uses isn’t a problem.
I mean it brings some benefits by way of alerting people to which packages the maintainers believe belong in nixpkgs, and this is not just a theoretical point: I was using the Zen browser until I was alerted to its security problems by the nixpkgs discussion about it.
But on the whole I agree with you at least to the extent that it’s not a big deal compared to the other considerations discussed above.
There is security risk by introducing a 3rd party (Determinate Systems) to provide this. I expect it has strong modern internal controls, but also has less community oversight than nixpkgs.
but are they not just mirroring nixpkgs?
It’s awfully convenient that they have the solution ready to go for you
but they have nixpkgs-weekly since 2024
I think that adding extra delay in consuming a NixOS release is a net negative. Instead of that we (all the commercial players) should invest in build capacity and people power to ship security fixes faster not slower. There are already some weeks passing by before security fixes that have to go through staging hit users.
Creating a “chilled” release is a marketing play that probably works well with already scared customers. But ultimately better security in NixOS comes from working with the community and not by spreading fear.
PS. I work on Cyberus Linux (formerly CTRL-OS), so I might not be an unbiased voice here either.
what would enable such solution? money? more nixos users (which eventually leads to more volunteers)?
I think that build scheduling plays a large role here. Just throwing more compute at the problem will just make more machines shuffling store paths around.
Wen there are 2 machines asking for a job we should consider what inputs they already have available to reduce substitution time.
This is especially cumbersome for wrappers of large packages.
I don’t know how much the improved hydra scheduler is already doing this, I can only talk about the nix built-in work scheduler.
