833957b374
This adds support to represent the `CA` field found in some .narinfo files. As `deriver`, it's also a subfield of the `narinfo` field. Extending nix-compat with a more accessible data structure that can take care of formatting, as well as writing validation functions in Rust + Golang, and integrating it into nar-bridge is something for a followup CL. Change-Id: I71e9c30957bcd03051a491aa54d7baac25b6dd2d Reviewed-on: https://cl.tvl.fyi/c/depot/+/9795 Autosubmit: flokli <flokli@flokli.de> Tested-by: BuildkiteCI Reviewed-by: Connor Brewster <cbrewster@hey.com>
128 lines
4.5 KiB
Protocol Buffer
128 lines
4.5 KiB
Protocol Buffer
// SPDX-License-Identifier: MIT
|
|
// Copyright © 2022 The Tvix Authors
|
|
syntax = "proto3";
|
|
|
|
package tvix.store.v1;
|
|
|
|
import "tvix/castore/protos/castore.proto";
|
|
|
|
option go_package = "code.tvl.fyi/tvix/store-go;storev1";
|
|
|
|
// PathInfo shows information about a Nix Store Path.
|
|
// That's a single element inside /nix/store.
|
|
message PathInfo {
|
|
// The path can be a directory, file or symlink.
|
|
tvix.castore.v1.Node node = 1;
|
|
|
|
// List of references (output path hashes)
|
|
// This really is the raw *bytes*, after decoding nixbase32, and not a
|
|
// base32-encoded string.
|
|
repeated bytes references = 2;
|
|
|
|
// see below.
|
|
NARInfo narinfo = 3;
|
|
}
|
|
|
|
// Represents a path in the Nix store (a direct child of STORE_DIR).
|
|
// It is commonly formatted by a nixbase32-encoding the digest, and
|
|
// concatenating the name, separated by a `-`.
|
|
message StorePath {
|
|
// The string after digest and `-`.
|
|
string name = 1;
|
|
|
|
// The digest (20 bytes).
|
|
bytes digest = 2;
|
|
}
|
|
|
|
// Nix C++ uses NAR (Nix Archive) as a format to transfer store paths,
|
|
// and stores metadata and signatures in NARInfo files.
|
|
// Store all these attributes in a separate message.
|
|
//
|
|
// This is useful to render .narinfo files to clients, or to preserve/validate
|
|
// these signatures.
|
|
// As verifying these signatures requires the whole NAR file to be synthesized,
|
|
// moving to another signature scheme is desired.
|
|
// Even then, it still makes sense to hold this data, for old clients.
|
|
message NARInfo {
|
|
// This represents a (parsed) signature line in a .narinfo file.
|
|
message Signature {
|
|
string name = 1;
|
|
bytes data = 2;
|
|
};
|
|
|
|
// This size of the NAR file, in bytes.
|
|
uint64 nar_size = 1;
|
|
|
|
// The sha256 of the NAR file representation.
|
|
bytes nar_sha256 = 2;
|
|
|
|
// The signatures in a .narinfo file.
|
|
repeated Signature signatures = 3;
|
|
|
|
// A list of references. To validate .narinfo signatures, a fingerprint
|
|
// needs to be constructed.
|
|
// This fingerprint doesn't just contain the hashes of the output paths of
|
|
// all references (like PathInfo.references), but their whole (base)names,
|
|
// so we need to keep them somewhere.
|
|
repeated string reference_names = 4;
|
|
|
|
// The StorePath of the .drv file producing this output.
|
|
// The .drv suffix is omitted in its `name` field.
|
|
StorePath deriver = 5;
|
|
|
|
// The CA field in the .narinfo.
|
|
// Its textual representations seen in the wild are one of the following:
|
|
// - `fixed:r:sha256:1gcky5hlf5vqfzpyhihydmm54grhc94mcs8w7xr8613qsqb1v2j6`
|
|
// fixed-output derivations using "recursive" `outputHashMode`.
|
|
// - `fixed:sha256:19xqkh72crbcba7flwxyi3n293vav6d7qkzkh2v4zfyi4iia8vj8
|
|
// fixed-output derivations using "flat" `outputHashMode`
|
|
// - `text:sha256:19xqkh72crbcba7flwxyi3n293vav6d7qkzkh2v4zfyi4iia8vj8`
|
|
// Text hashing, used for uploaded .drv files and outputs produced by
|
|
// builtins.toFile.
|
|
//
|
|
// Semantically, they can be split into the following components:
|
|
// - "content address prefix". Currently, "fixed" and "text" are supported.
|
|
// - "hash mode". Currently, "flat" and "recursive" are supported.
|
|
// - "hash type". The underlying hash function used.
|
|
// Currently, sha1, md5, sha256, sha512.
|
|
// - "digest". The digest itself.
|
|
//
|
|
// There are some restrictions on the possible combinations.
|
|
// For example, `text` and `fixed:recursive` always imply sha256.
|
|
//
|
|
// We use an enum to encode the possible combinations, and optimize
|
|
// for the common case, `fixed:recursive`, identified as `NAR_SHA256`.
|
|
CA ca = 6;
|
|
|
|
message CA {
|
|
enum Hash {
|
|
// produced when uploading fixed-output store paths using NAR-based
|
|
// hashing (`outputHashMode = "recursive"`).
|
|
NAR_SHA256 = 0;
|
|
NAR_SHA1 = 1;
|
|
NAR_SHA512 = 2;
|
|
NAR_MD5 = 3;
|
|
|
|
// Produced when uploading .drv files or outputs produced by
|
|
// builtins.toFile.
|
|
// Produces equivalent digests as FLAT_SHA256, but is a separate
|
|
// hashing type in Nix, affecting output path calculation.
|
|
TEXT_SHA256 = 4;
|
|
|
|
// Produced when using fixed-output derivations with
|
|
// `outputHashMode = "flat"`.
|
|
FLAT_SHA1 = 5;
|
|
FLAT_MD5 = 6;
|
|
FLAT_SHA256 = 7;
|
|
FLAT_SHA512 = 8;
|
|
|
|
// TODO: what happens in Rust if we introduce a new enum kind here?
|
|
}
|
|
|
|
// The hashing type used.
|
|
Hash type = 1;
|
|
|
|
// The digest, in raw bytes.
|
|
bytes digest = 2;
|
|
}
|
|
}
|