Expand description
cofre-types — typed secret-materialization primitives.
══════════════════════════════════════════════════════════════════════ What this crate is ══════════════════════════════════════════════════════════════════════
The pure-types half of the cofre toolchain. Defines:
SecretGenPolicy— how a secret is born (random, keypair, …)RotationPolicy— when it should be rotatedCharset— which alphabet random-generated values draw fromBackendKind— where the materialized value livesSecretRef— a typed pointer to one secret, with policySecretMaterializationPlan— manySecretRefs plus metadata, serializable to YAML/JSON for acofre applyinvocation
No I/O, no randomness, no backend code lives here — those concerns
belong in the cofre binary or in third-party SecretBackend impls.
This crate is pure types: load it, manipulate, validate, render.
══════════════════════════════════════════════════════════════════════ Why this crate exists ══════════════════════════════════════════════════════════════════════
Many tools generate secrets. Most of them put the plaintext on stdout at some point. Most of them hard-code one backend. Most of them have no notion of “this kind of password is constrained to ≤16 characters by the consuming protocol”.
cofre’s typed pipeline solves all three. By the time a generated
secret exists, the typescape has already proven (at compile time +
cargo test) that:
- the chosen length is compatible with the consumer (e.g. VNC’s
16-char ARD-XOR cap is structurally enforced via
max_length) - the requested charset is non-empty
- the rotation policy is consistent (e.g.
Neverrejects pairing with aManualrotation)
Validation is total before generation begins. Once cofre starts materializing, the only remaining failure modes are I/O.
══════════════════════════════════════════════════════════════════════ Compatibility ══════════════════════════════════════════════════════════════════════
Plans serialize to a stable YAML (and JSON) shape — the schema is part
of cofre’s public contract and is versioned via apiVersion. Adding
new variants to SecretGenPolicy is non-breaking; renaming or
removing them bumps the schema.