protocol: update JSON output with structured `Signature` type by amaanq · Pull Request #15009 · NixOS/nix

amaanq · 2026-01-16T19:46:34Z

Motivation

Previously, signatures were raw strings (in the format of keyName:base64sig) in JSON outputs. A proper Signature type in the JSON can improve this output by mimicking the inner Signature type used in the codebase.

Context

The JSON output uses a structured {keyName, sig} objects for Realisation and PathInfo V3. Additionally, V1 & V2 keeps the string format for backwards compatibility, and parsing accepts both formats.

The new JSON schemas introduced in this PR are signature-v1.yaml for the Signature type itself and store-object-info-v3.yaml for PathInfo with structured signatures.

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

Ericson2314 · 2026-01-22T22:42:38Z


 source common.sh

+requireDaemonNewerThan "2.34pre20260122"


Currently the daemon format just uses the latest JSON for which is bad, but I don't think it is worth fixing because we have some more serious Realisation/Build Trace JSON format changes right around the corner, after which there will be a harder compat break for this unstable feature, and I also took that opportunity to make it stop using JSON so we won't have this versioning issue again.

We should be able to delete this now!

xokdvium · 2026-01-26T17:59:51Z

+    j = {
+        {"keyName", s.keyName},
+        {"sig", base64::encode(std::as_bytes(std::span<const char>{s.sig}))},
+    };


I'm not sure what this gets us in terms of immediate benefits? The signature itself is still a binary blob that's supposed to be ed25519.

It is used in nix path-info, but that is already versioned

It is used in realisations, but those are going to be subject to breaking changes anyways. We have back compat in the reading direction (just not writing direction) too.

Ericson2314 · 2026-01-26T19:30:17Z

+  keyName:
+    type: string
+    title: Key Name
+    description: The name of the key used to produce this signature
+  sig:
+    type: string
+    title: Signature Data
+    description: The raw signature bytes, Base64-encoded


Add algorithm field? Something that is ed25519 currently?

CC @mschwaig @edef1c

Ericson2314 · 2026-03-02T22:57:11Z

- Version 1: Original format - Version 2: - Remove `dependentRealisations` - Version 3: - Use `drvPath` not `drvHash` to refer to derivation in a more conventional way. - Separate into `key` and `value` - Use 2nd version of signatures format (objects, not strings)

We should have this in the version history, and this should be named to `v3 accordingly.

This commit updates the JSON output with a Signature type containing keyName and sig fields. JSON parsing accepts both formats for backwards compatibility. Co-authored-by: John Ericson <John.Ericson@Obsidian.Systems>

Ericson2314

The concern with this was that we were churning the formats, but now that we are changing realisations in a breaking way anyways (drv hash -> drv path) there is essentially no marginal cost of doing this

protocol: update JSON output with structured `Signature` type

amaanq requested review from Ericson2314 and edolstra as code owners January 16, 2026 19:46

github-actions Bot added documentation new-cli Relating to the "nix" command store Issues and pull requests concerning the Nix store labels Jan 16, 2026