ssh-tpm-agent: keyutils (fixes #505869)

[vorburger]

Things done

Fixes #505869.

This is my very 1st PR to nixpkgs... let me know if this is cool, or if anything more is needed?

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[Copilot]

Pull request overview

This PR addresses nixpkgs issue #505869 by attempting to ensure ssh-tpm-agent can access keyctl (from keyutils) in minimal/non-graphical environments where it may not already be present.

Changes:

• Add keyutils as an input to the ssh-tpm-agent derivation.
• Include keyutils in buildInputs alongside openssl.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Adding keyutils to buildInputs alone typically won’t make keyctl available at runtime for ssh-tpm-agent (the Go binary won’t reference the keyutils store path, and systemd/user shells may not have it on PATH). To actually fix the missing keyctl dependency, wrap ssh-tpm-agent (e.g., via makeWrapper + postInstall with --prefix PATH : ${lib.makeBinPath [ keyutils ]}) or otherwise ensure keyutils ends up in the runtime closure and PATH.

[tree-sapii]

Hey! Congrats on your first contrib and fix. I reviewed it and I am not going to listen to what Copilot said, and say that yes including a package in the buildInputs arg of a drv adds them as a runtime dependency, however make sure this 100% by building it and running it from /result/bin as specified in the PR template.

Good stuff!

[wishstudio]

I think Copilot is correct here. This won't work. The buildInput attribute, as the name suggests, only specifies build dependencies. nix automatically figures out runtime dependencies by searching for store paths in the build result.

You can use the following command to check the dependency of a package.

nix-store --query --references <nix store path>

The result I got for this PR:

[nix-shell:~/.cache/nixpkgs-review/pr-505874/logs]$ nix-store --query --references /nix/store/9g835hzhhb09fv4w11m1lhypb918pjba-ssh-tpm-agent-0.8.0
/nix/store/2ly61i1c0ipwq73w2102lr6px5mlfsjb-iana-etc-20251215
/nix/store/a6kd5v5x97jnyyzbmiild0m1ikn5yfmg-mailcap-2.1.54
/nix/store/jms7zxzm7w1whczwny5m3gkgdjghmi2r-glibc-2.42-51
/nix/store/bga5xf95jaypy385hvxm4h3yxl3m1566-openssl-3.6.1
/nix/store/h15ranlgwagilr6ajd7ich6d896kf9zd-tzdata-2026a

You can read this nixpills article for more information.

[vorburger]

@wishstudio Thank You, I think I see what you mean. How would I write an (currently expected to be failing) Integration Test in nixpkgs which "runs keyctl on the PATH that package ssh-tpm-agent has at runtime" ?

[tree-sapii]

So after reading the src of go's unix library that ssh-tpm-agent interacts with to to keyctl stuff, I originally thought that it would just link against the keyctl library ( keyctl itself is a syscall ), but if its does really need the binary keyctl, then yes you need to wrap it to set the path.

Make sure to import makeWrapper and keyutils and pass them into buildInputs.
This is what you'd add to the drv:

  postFixup = ''
  wrapProgram $out/bin/ssh-tpm-agent \
    --set PATH ${lib.makeBinPath [
      keyutils
    ]}
  '';

This builds on my system, however I haven't done any tests.

If this is anything to go by, then it works:

nix-store --query --references  /nix/store/4ykvxi8p8z3m4awn0i03jgkyw6q0qvzc-ssh-tpm-agent-0.8.0
/nix/store/2ly61i1c0ipwq73w2102lr6px5mlfsjb-iana-etc-20251215
/nix/store/a6kd5v5x97jnyyzbmiild0m1ikn5yfmg-mailcap-2.1.54
/nix/store/jms7zxzm7w1whczwny5m3gkgdjghmi2r-glibc-2.42-51
/nix/store/bga5xf95jaypy385hvxm4h3yxl3m1566-openssl-3.6.1
/nix/store/h15ranlgwagilr6ajd7ich6d896kf9zd-tzdata-2026a
/nix/store/v8sa6r6q037ihghxfbwzjj4p59v2x0pv-bash-5.3p9
/nix/store/jbsc7gkd508h1wsvfx3l8am18hx3bjc0-keyutils-1.6.3
/nix/store/4ykvxi8p8z3m4awn0i03jgkyw6q0qvzc-ssh-tpm-agent-0.8.0

[NickCao]

I believe that line of code is misleading, if you look into https://github.com/Foxboron/ssh-tpm-agent/tree/e8cd6307ad832c37dc613942cc7298e43694348e/internal/keyring, it's doing syscalls directly, not using the keyctl cli.

[wishstudio]

I believe that line of code is misleading, if you look into https://github.com/Foxboron/ssh-tpm-agent/tree/e8cd6307ad832c37dc613942cc7298e43694348e/internal/keyring, it's doing syscalls directly, not using the keyctl cli.

Not an expert in this field. But if you look at the manpage of keyutils:

       The kernel has the ability to upcall to userspace to fabricate new
       keys.  This can be triggered by request_key(), but userspace is
       better off using add_key() instead if it possibly can.

and in kernel doc:

A request proceeds in the following manner:

1. Process A calls request_key() [the userspace syscall calls the kernel interface].

...

4. request_key() then forks and executes /sbin/request-key with a new session keyring that contains a link to auth key V.

So the kernel may call back to the userspace utility when executing the system call.

[NickCao]

I believe that line of code is misleading, if you look into https://github.com/Foxboron/ssh-tpm-agent/tree/e8cd6307ad832c37dc613942cc7298e43694348e/internal/keyring, it's doing syscalls directly, not using the keyctl cli.

Not an expert in this field. But if you look at the manpage of keyutils:

       The kernel has the ability to upcall to userspace to fabricate new
       keys.  This can be triggered by request_key(), but userspace is
       better off using add_key() instead if it possibly can.

and in kernel doc:

A request proceeds in the following manner:

1. Process A calls request_key() [the userspace syscall calls the kernel interface].

...

4. request_key() then forks and executes /sbin/request-key with a new session keyring that contains a link to auth key V.

So the kernel may call back to the userspace utility when executing the system call.

Yes, but the request-key helper does not come from PATH, See pkgs/os-specific/linux/kernel/request-key-helper.patch

[tree-sapii]

Yet, /run/current-system/sw/bin/request-key doesn't exist on my system and I'm assuming on his too, so the kernel will try to call into userspace and fail and the program interprets that as keyutils don't exist.

[NickCao]

Yet, /run/current-system/sw/bin/request-key doesn't exist on my system and I'm assuming on his too, so the kernel will try to call into userspace and fail and the program interprets that as keyutils don't exist.

In that case, add environment.systemPackages = with pkgs; [ keyutils ]; to your system configuration.

[wishstudio]

Yes, but the request-key helper does not come from PATH, See pkgs/os-specific/linux/kernel/request-key-helper.patch

Nevermind. I misunderstood what you mean.
Anyway, this is an indirect call and I have no idea of the idiomatic way of handling this (or do we handle this at all?).

[tree-sapii]

Yet, /run/current-system/sw/bin/request-key doesn't exist on my system and I'm assuming on his too, so the kernel will try to call into userspace and fail and the program interprets that as keyutils don't exist.

In that case, add environment.systemPackages = with pkgs; [ keyutils ]; to your system configuration.

Then this is the solution. @vorburger, you can create a module for this package that starts up a service as well as adds the keyutils package to systemPackages.

[vorburger]

Then this is the solution. @vorburger, you can create a module for this package that starts up a service as well as adds the keyutils package to systemPackages.

Sounds like a plan! We'll close this?

[tree-sapii]

Then this is the solution. @vorburger, you can create a module for this package that starts up a service as well as adds the keyutils package to systemPackages.

Sounds like a plan! We'll close this?

Sure.