I’ve recently merged and become the maintainer for openclaw which has an incredible number of updates (at least a few times a week). There are also a number of CVEs filed for it routinely which mean we should keep it updated as quickly as we can.
I agreed in my initial PR to mark it insecure because how much control software like OpenClaw has, but it has made trying to get auto updates working very difficult. Without properly getting r-ryantm configured correctly I need to rely on those with commit rights to approve any PRs to update OpenClaw.
I tried to configure r-ryantm so it would be easier to approve updates automatically, but it is getting stuck in the build/eval stages because it’s marked insecure despite adding NIXPKGS_ALLOWED_INSECURE=1 to the environment where nix-update is run.
This was the latest run I saw https://nixpkgs-update-logs.nix-community.org/openclaw/2026-04-06.log
I’m not sure how to replicate the steps r-ryantm is doing and couldn’t find any instructions at nixpkgs/maintainers/README.md at 8ad72d81b584ed765946b72021ef8db258fe390f · NixOS/nixpkgs · GitHub
Is there some way for me to fix this without marking the package not insecure?
1 Like
r-ryantm won’t perform multiple updates on any package per week since it deprioritizes packages after an update in order to free up resources for other packages to be updated. So you probably want to look for an alternative solution anyways.
2 Likes
See previously: allow nixpkgs-review to build insecure packages by zowoq · Pull Request #391 · nix-community/nixpkgs-update · GitHub (we supported it for a few months pretty much just because openssl_1_1 was getting special treatment, but then we reverted it).
Oh I saw. That doesn’t really answer anything.
Sure; I just wanted the OP to have a handle to it for context.
A side note, per nixpkgs/pkgs/README.md at 21a4472363a361d6a2564e643ccc70cd2d0cacf9 · NixOS/nixpkgs · GitHub
Any security-critical fast-moving package such as Chrome or Firefox (or their forks) must have at least one committer among the maintainers, who actively reviews, merges and backports updates. This ensures no critical fixes are delayed unnecessarily, endangering unsuspecting users.
In this case that would be mkg20001, and it would be contingent upon them merging in a timely manner regardless. Since there’s multiple updates per week, you may also want to look into having your own bot set up to send PRs for the specific package (assuming it follows all contribution guidelines).
1 Like