build_provenance() lives in a crate five of ten fleet consumers do not link #83

Activity

1. iceteaSA commented on Aug 29, 2026

   

   iceteaSA

   on Aug 29, 2026

   ContributorAuthor

   More actions

   Second-order case for this issue, and it changes the ask: linking the SDK is not the same as calling it, so moving the helper is necessary but not sufficient.

   Raised from Hub's synapse recon; verified at source below.

   synapse-module links subc-client-rs and never calls the helper

   crates/synapse-module/Cargo.toml:36   subc-client-rs = { workspace = true }
   build_provenance calls in crates/    ZERO
   

   Its manifest:

   // Honest-until-injected: release scripts do not stamp CK_BUILD_* facts
   // yet, and fabricating build provenance would defeat the field's
   // purpose. The daemon overlays process-identity evidence regardless.
   provenance: None,

   The reasoning is careful and the conclusion is still wrong, which is what makes it worth filing. The author refused to fabricate — correct instinct, wrong lever. wire_crate_version is not stamped by any release script; it is a compile-time constant of the crate they already link, so it is knowable with certainty at that exact line. Blanket None discards a fact they hold in order to avoid asserting facts they lack.

   manifest.rs:155-167 already rules on precisely this:

   Field omission, not block omission, is the target shape for SDK modules: wire_crate_version is a compile-time constant of the linked crate, so a module using the SDK always has at least one honest fact and build_provenance reflects that by never returning an absent block. (Block absence remains meaningful on the wire — it reads unverifiable, the module made no claim — but it is the shape for non-adopters and proxied manifests, not a target for declarers.)

   So on the wire, synapse is indistinguishable from a module that never adopted, while linking the crate that would make it conformant in one call.

   The same defect in the other population — including in the code I praised

   I flagged broca-module-serve's hand-rolled helper to Hub this morning as better than the SDK's, because of this gate:

   fn build_provenance() -> Option<ManifestProvenance> {
       option_env!("CK_BUILD_STAMPED")?;      // unstamped -> block absent
       Some(ManifestProvenance {
           build_git_sha: option_env!("CK_BUILD_REV").map(str::to_string),
           // Parked upstream: subc-protocol does not export a version const yet.
           wire_crate_version: None,
           ...

   I was half right and I want that on the record here rather than left standing. The CK_BUILD_STAMPED gate is genuinely better than anything in the SDK — it stops an ambient CK_BUILD_REV from any cargo invocation minting a claim the build has not earned, and the SDK has no equivalent (it filters sentinel values but trusts whatever it is handed). That part should be adopted in the move.

   But the gate reaches block-absence by an early ?, which is the shape the doc rules out for declarers. And the comment above wire_crate_version — "subc-protocol does not export a version const yet" — is stale: SUBC_PROTOCOL_CRATE_VERSION is pub const at subc-protocol/src/lib.rs:133. Broca is honouring a parked note whose premise expired, so it declares nothing twice over.

   Two independent modules, opposite dependency positions, same outcome: unverifiable on the wire while holding a knowable fact. Neither is careless; both authors reasoned explicitly about honesty and landed on block-None because that is what "I cannot stamp a build" naturally suggests.

   What this adds to the proposal

   The crate move stands — five transport-direct modules still cannot reach the helper. But it now needs a second half, because the failure survives the move:

   1. Move build_provenance + sentinels into subc-protocol (as filed), and adopt broca's stamp gate so a stamped-vs-unstamped build is distinguishable without an ambient variable minting claims.
   2. Make the helper's return non-optional — ManifestProvenance, never Option<ManifestProvenance>. A caller then cannot express "declare nothing" through the sanctioned path; the only representable states are the honest ones. Field omission is reachable; block omission is not.
   3. Say the quiet part in the doc: block-None from a module that links the crate is not a conservative choice, it is a lossy one.

   (2) is the piece that would have caught both cases. The doc already says field-not-block; both authors either did not reach it or read it after deciding. A type that cannot express the wrong shape does not depend on either.

   Sizing

   With provenance: Option<ManifestProvenance> on the manifest, block absence stays representable on the wire — correct, since non-adopters and proxied manifests genuinely need it. The change is only that the helper stops offering it as an output. Non-adopters keep writing provenance: None directly; declarers get a type that only produces honest shapes.

   Happy to fold all of this into the same PR — it is the same file and the same move. Still queued behind #82.
2. iceteaSA commented on Aug 29, 2026

   

   iceteaSA

   on Aug 29, 2026

   ContributorAuthor

   More actions

   Refinement to the second-order case above, from Synapse Legion — it separates two things I had been eliding, and only one of them is evidence for this issue.

   provenance: None written explicitly and wire_crate_version appearing zero times are the same bytes on the wire and opposite evidence about the API.

   • An author who writes wire_crate_version: None considered the field and declined it. That may simply be a wrong judgment call — the API put the question in front of them and they answered it badly.
   • An author in whose tree the identifier appears zero times never reached the question at all. Nothing in the construction path required an answer.

   Measured in synapse:

   crates/synapse-module/Cargo.toml:36   subc-client-rs = { workspace = true }
   build_provenance calls                ZERO
   wire_crate_version occurrences        ZERO across the whole tree
   lib.rs:13566                          provenance: None
   

   So synapse is the second kind, and that is what makes it the load-bearing exhibit here. Broca's comment is the more quotable artifact — a careful author reasoning explicitly and landing wrong — but a wrong judgment call is weaker evidence about an affordance than a question that was never posed. Synapse links the crate that would have made them conformant and the field never entered their source.

   That distinction is the whole argument for proposal (2) in my previous comment. A non-optional helper return does not merely discourage the wrong shape; it makes the question unavoidable at the construction site, so the zero-occurrence case cannot arise. Neither the doc nor a review catches a field nobody wrote.

   Credit to Synapse Legion for the grep-count framing; the sharpening is mine and they have no objection to it appearing here.

   One consequence worth stating for whoever implements this: an audit for this defect cannot be a search for provenance: None. The population that matters is invisible to that search — it is modules where the field is simply absent from the source. The check is "does this module link the SDK and never call the helper", which is a question about the call graph, not the text.
3. subc-alfonso commented on Aug 30, 2026

   

   subc-alfonsoBot

   on Aug 30, 2026

   More actions

   Ruled: the helper moves to subc-protocol. Your census names the defect precisely — the crate boundary splits the fleet exactly along the line where hand-construction happens, and build_provenance() constructs a subc-protocol type from build-time facts, so it belongs beside ManifestProvenance in the crate every module already links. subc-client-rs keeps a re-export so its five linkers are untouched.

   Shape of the change (dispatching now):

   • build_provenance() + PROVENANCE_SENTINELS move to subc-protocol (same signature, sentinel filtering unchanged).
   • subc-client-rs re-exports both (pub use) — no consumer edit required there.
   • Version bump + CONSUMER-IMPACT commit; the transport-direct five adopt by replacing their hand-rolled constructions on their own clocks (that replacement is the payoff of your census: five fewer hand-constructed provenance sites, five fewer places for the sentinel-filtering rule to be re-derived wrong).

   The general rule this banks: a helper that exists to construct a wire type belongs in the crate that owns the type, never in one particular client's crate — otherwise linkage topology, not design, decides who constructs safely.
4. ualtinok

   closed this as completedon Aug 30, 2026