2022-10-28 16:26:32 +02:00
|
|
|
// SPDX-License-Identifier: MIT
|
|
|
|
// Copyright © 2022 The Tvix Authors
|
|
|
|
syntax = "proto3";
|
|
|
|
|
|
|
|
package tvix.store.v1;
|
|
|
|
|
2023-09-21 21:32:44 +02:00
|
|
|
import "tvix/castore/protos/castore.proto";
|
2022-10-28 16:26:32 +02:00
|
|
|
|
2023-10-17 22:30:29 +02:00
|
|
|
option go_package = "code.tvl.fyi/tvix/store-go;storev1";
|
2022-11-19 22:20:14 +01:00
|
|
|
|
2022-10-28 16:26:32 +02:00
|
|
|
// PathInfo shows information about a Nix Store Path.
|
|
|
|
// That's a single element inside /nix/store.
|
|
|
|
message PathInfo {
|
2023-12-09 14:23:29 +01:00
|
|
|
// The path can be a directory, file or symlink.
|
|
|
|
tvix.castore.v1.Node node = 1;
|
2022-10-28 16:26:32 +02:00
|
|
|
|
2023-12-09 14:23:29 +01:00
|
|
|
// 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;
|
2022-10-28 16:26:32 +02:00
|
|
|
|
2023-12-09 14:23:29 +01:00
|
|
|
// see below.
|
|
|
|
NARInfo narinfo = 3;
|
2022-12-23 18:53:57 +01:00
|
|
|
}
|
|
|
|
|
2023-10-10 23:06:42 +02:00
|
|
|
// 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 {
|
2023-12-09 14:23:29 +01:00
|
|
|
// The string after digest and `-`.
|
|
|
|
string name = 1;
|
2023-10-10 23:06:42 +02:00
|
|
|
|
2023-12-09 14:23:29 +01:00
|
|
|
// The digest (20 bytes).
|
|
|
|
bytes digest = 2;
|
2023-10-10 23:06:42 +02:00
|
|
|
}
|
|
|
|
|
2022-10-28 16:26:32 +02:00
|
|
|
// 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 {
|
2023-12-09 14:23:29 +01:00
|
|
|
// 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?
|
2023-10-19 14:50:05 +02:00
|
|
|
}
|
2023-12-09 14:23:29 +01:00
|
|
|
|
|
|
|
// The hashing type used.
|
|
|
|
Hash type = 1;
|
|
|
|
|
|
|
|
// The digest, in raw bytes.
|
|
|
|
bytes digest = 2;
|
|
|
|
}
|
2022-10-28 16:26:32 +02:00
|
|
|
}
|