We are marking `resholve` itself with `meta.knownVulnerabilities`, and
overriding `resholve-utils` functions's `resholve` with
`meta.knownVulnerabilities = [ ]`.
This way, we can still use `resholve` at build-time without triggering
security warnings, however we can't instantiate `resholve` itself. See:
```
$ nix-build -A resholve
error: Package ‘resholve-0.8.4’ in /.../nixpkgs/pkgs/development/misc/resholve/resholve.nix:48 is marked as insecure, refusing to evaluate.
$ nix-build -A ix
/nix/store/k8cvj1bfxkjj8zdg6kgm7r8942bbj7w7-ix-20190815
```
For debugging purposes, you can still bypass the security checks and
instantiate `resholve` by:
```
$ NIXPKGS_ALLOW_INSECURE=1 nix-build -A resholve
/nix/store/77s87hhqymc6x9wpclb04zg5jwm6fsij-resholve-0.8.4
```
Forgot to port this resholve Nix API fix in the course of #184292.
Same change as:
github.com/abathur/resholve/commit/b743d2eb12d82e35c567733a7a884174e3606641
This PR strips down the modified `python27` derivation used by `resholve`. The
idea is to reduce the possible security issues, and also to make it easier to
bootstrap.
Effort to fix automatic nixpkgs-update updates for resholved
packages in 9f6310d did help the bot get further, but it
then failed to find the source outputHash (the outer
derivation's source is the inner derivation; bot looks for
outer.src.outputHash; ours is at outer.src.src.outputHash).
This change uses `originalSrc` to indicate the source of the
inner derivation. Along with ryantm/nixpkgs-update#324, this
enables the bot to fall back on an attr that Nix/nixpkgs are
not directly depending on, supporting automatic updates for
packages built with `resholve.mkDerivation`.
Two items in resholve's mkDerivation are causing trouble for
some ecosystem tools:
1. I didn't pass through the original package's meta, which breaks the
ability of at least nixos package search and r-ryantm to find the
right source file (in the latter case breaking auto updates).
2. I was prepending "resholved-" to the pname, which at least nixos
package search picks up as the package's name. Repology also tries
to do this, but their current nix updater will prefer to get this
data from the name. For now, this means changing to name will not
stop repology from picking up the `resholved-<package>` names.
Repology's code makes it clear that they *want* to use the pname/
version, so I was inclined to settle with what I've got for now,
but thiagokokada clarified that we aren't just waiting for nixpkgs
fixes, but because Nix itself isn't exporting the pname/version in
its JSON. See also:
- https://github.com/repology/repology-updater/issues/854
- https://github.com/repology/repology-updater/commit/9313110121df5
For now, at least, I'll switch to appending "-unresholved" to the
inner derivation's pname.
Extract argument-handling utility functions to prepare for adding
resholveScript* functions.
This tracks upstream work, but I broke it up a little more semantically here
in case it aids review. See:
6aab748205
A bit going on here.
- Updating resholve from 0.5.1 -> 0.6.0
- adding a depdendency, `binlore`, to supply ~intel on executables
that supports new functionality in resholve
- adding a package, `yallback`, which provides rule-based callbacks
for YARA rule matches (depdency of `binlore`).
- automatically generating "lore" for each `input` to a solution in
`resholvePackage`.
- update README
- restructuring some nix components to better support
my local dev and CI workflows.
- moved package tests into passthru/tests.nix (cuts `bats` out of
resholve's immediate dependencies, makes it possible to add my
existing Nix API test).
- move my oil-dev patches out of resholve into a separate repo (no
oil rebuild every time resholve's source changes). Also moving
oil-dev into its own Nix file here, to ~track the default.nix in
its own repo.
resholve: init at 0.4.0
resholve attempts to resolve executables in shell scripts.
Includes Nix builder for resolving dependencies in Nix-built
shell projects.