Add: nix flakes support

[arch-fan]

What:

A flake.nix that builds the entire openvas-scanner workspace — the C openvas scanner and the Rust openvasd/scannerctl/feed-filter binaries — pinned to the same source tree.

nix build .#openvasd
nix run   .#scannerctl -- --help
nix flake check

Why:

I think it's interesting to have Nix flakes to make a way of native building and distribution.

How:

C scanner: built from source with CMake. Reuses gvm-libs from nixpkgs (22.31.1 — the scanner only needs ≥22.4). Uses substituteInPlace to strip -Werror from the CMake files rather than a blanket NIX_CFLAGS_COMPILE. Installs via DESTDIR with standard FHS paths; autoPatchelfHook fixes RPATH since the non-standard install layout bypasses the Nix linker wrapper.

Rust scanner: built with crane and fenix. Each workspace binary is its own derivation sharing a single buildDepsOnly cache. The nasl-c-lib -sys crates are the trickiest part — they use a custom build_support.rs that discovers native libraries through $OPENVAS_ARCHIVES rather than pkg-config. The flake works around this with:

• A buildCache derivation that symlinks libgcrypt, libgpg-error, and Kerberos .so files + headers into the flat layout the -sys crates expect.
• A postPatch that switches cargo:rustc-link-lib=static= → dylib= and .a → .so so Nix's shared libraries are used instead of the upstream static archive convention (those static archives are produced by an upstream Docker-only "build-archives" stage and aren't reproducible outside that environment).
• autoPatchelfHook restores RPATH on the final binaries since the -sys crates emit direct cargo:rustc-link directives that bypass the stdenv linker wrapper.

Tests: enabled by default (doCheck = true) on the per-binary builds — 64 pass. The container_image_scanner tests are skipped (they need a Docker registry in the sandbox). The full workspace build has doCheck = false because cargo test --lib hits nasl::builtin::sys::tests::find_in_path which SIGABRTs in the sandbox; no coverage is lost since the per-binary builds exercise the same code.

Fragility notes

• sha256 in fromToolchainFile (flake.nix:31) — needs updating when rust/rust-toolchain.toml changes channel.

To be discused

Depending on the level of adoption of flakes, some points must be discussed:

• CI — nix flake check should gate PRs.
• Supporting nixos or home manager modules would be interesting for easy deploying & configuration. They would be tested by using the nixos' vm output.
• Version actually parsed from CMakeLists.txt on the openvas project. Maybe we should use a easier way to declare version.
• At the moment we use nixpkgs' gvm-libs, but it may be interesting to package it here.
• Fill manteiners on meta block
• Also package ospd-openvas?

Checklist:

• Test - x86_64-linux
• Test - aarch64-linux
• PR merge commit message adjusted

[arch-fan]

@team, please review the package build. I made a few decisions myself regarding compile flags, paths, and a few other details.

If you have any questions about flakes, just ask. I’ll do my best to help.

[arch-fan]

No problem with Darwin because is deprecated since 26.05 nixos 🤣🤣

Ok, I'll remove it

[nichtsfrei]

Thank you very much for this PR :).

[nichtsfrei]

Regarding gvm-libs: I think it would be better to not use the one provided in nixpkgs as openvas assumes the latest gvm-libs version to be available. So when it is not updated on nixpkgs in time the nix check would fail, which is a bit annoying to debug within a pipeline.

[arch-fan]

Regarding gvm-libs: I think it would be better to not use the one provided in nixpkgs as openvas assumes the latest gvm-libs version to be available. So when it is not updated on nixpkgs in time the nix check would fail, which is a bit annoying to debug within a pipeline.

Ok, but this has a problem: version has to be manually bumped at nix package... OR, have a source of truth on the repo that makes possible to choose the gvm-libs version.

[arch-fan]

And should we package ospd-openvas? or just focus on newer scannerctl & openvasd?

[Tehforsch]

And should we package ospd-openvas? or just focus on newer scannerctl & openvasd?

I think just scannerctl and openvasd is probably the smarter choice

[arch-fan]

I also think so.

Ok, so we should discuss the "To be discussed" section on the PR.

What do you all think?

[nichtsfrei]

CI — nix flake check should gate PRs.

Yup, totally for that.

Supporting nixos or home manager modules would be interesting for easy deploying & configuration. They would be tested by using the nixos' vm output.

Do you mean exporting the configuration options for openvas and openvasd with the additional redis running on unix socket mode when activated as a service? Would be cool, but could also be done afterwards.

Version actually parsed from CMakeLists.txt on the openvas project. Maybe we should use a easier way to declare version.

We actually just use the tags as a source of truth when we generate a release. So we could do the same and check if an environment variable (within the CI) is set then use version otherwise it is a git sha1?

[nichtsfrei]

we just use the toolchain so that we are not so often surprised by clippy and fmt changes and can do that when we have time. Since we don't validate clippy nor formatting via nix I don't think it is necessary to respect the toolchain definition?

[arch-fan]

Well, toolchain is loaded mainly because of the Rust version, so we can have it fixed. Clippy & formatting are extra tools, but not necessary.

I can remove the toolchain usage but that means that Rust version will be set by fenix's input lock at flakes.

[nichtsfrei]

Ok, but this has a problem: version has to be manually bumped at nix package... OR, have a source of truth on the repo that makes possible to choose the gvm-libs version.

Usually openvas just depends on the latest gvm-libs version so for main or the latest release it shouldn't be an issue. So for now it is fine as we have the same breakage point when openvas is build from source by release tag and I think also when the container image is being rebuild on a tag.

But I agree on release we should come up with a mechanism to store the used gvm-libs version so that openvas can be rebuild with that instead of hoping the latest gvm-libs version is still compatible.

[arch-fan]

CI — nix flake check should gate PRs.

Yup, totally for that.

Well, for CI I also think would be great, but that escapes from my scope

Supporting nixos or home manager modules would be interesting for easy deploying & configuration. They would be tested by using the nixos' vm output.

Do you mean exporting the configuration options for openvas and openvasd with the additional redis running on unix socket mode when activated as a service? Would be cool, but could also be done afterwards.

Yep, i mean that, but ok, let's first focus on packaging everything right.

Version actually parsed from CMakeLists.txt on the openvas project. Maybe we should use a easier way to declare version.

We actually just use the tags as a source of truth when we generate a release. So we could do the same and check if an environment variable (within the CI) is set then use version otherwise it is a git sha1?

Nop, nix is deterministic and can only extract data from the actual state of the repo. For example, it could extract the actual commit's hash, but tag cannot be retrieved. To be able to read env vars, we should use nix with the --impure tag, and that's not the right path for Nix.

[arch-fan]

Usually openvas just depends on the latest gvm-libs version so for main or the latest release it shouldn't be an issue. So for now it is fine as we have the same breakage point when openvas is build from source by release tag and I think also when the container image is being rebuild on a tag.

Ok, so I will take the approach of using the latest available and remember to bump it from time to time

But I agree on release we should come up with a mechanism to store the used gvm-libs version so that openvas can be rebuild with that instead of hoping the latest gvm-libs version is still compatible.

Definetly 😂. Even if you pin the Docker image, I could extract it from there 🤣🤣 I think isn't the best way, but it would work.