nix-eda-packaging — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited nix-eda-packaging (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
EDA tools are awkward Nix citizens: they dlopen plugins at runtime, expect data files at fixed paths, and ship as prebuilt binaries with bad assumptions about the filesystem. The temptation is to paper over each failure with a wrapper or a binary patch. The discipline is to fix the actual dependency so the package is honest about what it needs.
Core principle: Make the package's real dependencies explicit, don't disguise them. A wrapProgram that injects a path or a patchelf that rewrites an interpreter hides a missing dependency instead of declaring it, and it breaks the next person who builds on your package.
These are the moves to avoid, and what they're hiding:
buildInputs and on the proper rpath, or the plugin belongs in a declared search path the program already honors.autoPatchelfHook) only as a last resort and only for genuinely closed binaries, not to dodge a dlopen issue in something you build from source.NEEDED entries; it does not solve a runtime dlopen("libfoo.so") that searches a path you haven't set up. Reaching for it here means you're treating the wrong layer.When a dlopen fails, find what the tool actually dlopens and at what path, then provide that path the way the tool expects (a real search path, a data dir, an env the program documents) rather than wrapping the binary.
When you need a custom build or install phase, write the phase as a build-phase string. Do not try to pass derivation outputs like $out through command-line-builder helpers (the toCommandLineShellGNU-style functions); $out is a shell variable that only exists at build time inside the phase, and threading it through a Nix-level argument builder produces the wrong thing.
# Right: $out is referenced inside the phase string, where it exists.
buildPhase = ''
make PREFIX=$out -j$NIX_BUILD_CORES
'';
# Wrong: trying to bake $out into a CLI arg list at Nix eval time.
# $out is not defined then; the helper sees a literal or empty value.nix eval/nix build and don't assume x86_64 in scripts or test invocations.| Smell | Do instead |
|---|---|
wrapProgram --set LD_LIBRARY_PATH to fix dlopen | Declare the dep; put the lib on rpath or the documented search path |
Hand patchelf to fix a from-source build | Fix the link / buildInputs |
autoPatchelfHook to solve a dlopen | Provide the runtime search path the tool expects |
Threading $out through a CLI-arg helper | Reference $out inside the buildPhase string |
| Assuming x86_64 on the dev box | It's aarch64-linux |
wrapProgram/patchelf/autoPatchelfHook to paper over dlopen issues. Fix the real dependency.$out through toCommandLineShellGNU-style helpers.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.