Multiple fixes: several secrets per module (069), ask a module's tool (049), copy an upstream image (046), declare a vendor image (064) #38

2026-09-21T18:49:16Z

jschoubben commented

2026-09-21 18:49:16 +00:00

Four issues on one branch, one commit group each, one decision record each (hq MR on the same branch name).

069 — several secrets from one provider (ADR 0094)

secrets: maps a requirement to several files under local names. Each local name is its own need (expanded in the per-consumer pass, where the consumer is known), its own pair credential (migration 0027 adds local to the key; every existing row keeps ''), its own file on the consumer (${secret:<local>}), its own holder at the provider (<identity>_<local>, its own grant file), and rotates apart. rotate and secret accept --provider --local carry it. Along the way: a need is now kept once per (provision, consumer, local, provider) — two consumers of one same-node provision used to produce the same credential twice for each.

049 — the control plane is the way to ask (ADR 0095)

ask <module> <tool> [json] publishes on mesh.rpc with a private reply queue bound under its own name, checks the correlation, prints the answer, exits non-zero for a tool that answered with an error or a module that never answered.

046 — an upstream image is copied between registries (ADR 0096)

The builder reads the index and every manifest it names over the registry API (anonymous bearer token on challenge), moves each blob by digest into the mesh's registry, puts the manifests and then the index under the module's repository, and pins the index. Genesis keeps the pull. Tested against a fake upstream serving an index over two platforms and a fake mesh registry.

064 — a vendor image is a declared build input (ADR 0097)

build.on takes {arg, image@sha256:…}; the image is copied in before the build and handed to the recipe. A COPY --from of an undeclared registry image is refused before the build; an undeclared FROM is said, not refused — the mesh's own images start FROM a public base, and refusing them refuses genesis. The package half of 064 stays open (needs a rerun).

Proven

go test ./... green with MESH_TEST_POSTGRES. Lab, against a controller image built from this branch: assigned-vault 4/4 with a two-secrets consumer (two values, two ledger holders, both rotated); assigned-tools-confluence green including an ask through the control plane that got the tool's answer.

Four issues on one branch, one commit group each, one decision record each (hq MR on the same branch name). ## 069 — several secrets from one provider (ADR 0094) `secrets:` maps a requirement to several files under local names. Each local name is its own need (expanded in the per-consumer pass, where the consumer is known), its own pair credential (migration 0027 adds `local` to the key; every existing row keeps `''`), its own file on the consumer (`${secret:<local>}`), its own holder at the provider (`<identity>_<local>`, its own grant file), and rotates apart. `rotate` and `secret accept --provider --local` carry it. Along the way: a need is now kept once per (provision, consumer, local, provider) — two consumers of one same-node provision used to produce the same credential twice for each. ## 049 — the control plane is the way to ask (ADR 0095) `ask <module> <tool> [json]` publishes on `mesh.rpc` with a private reply queue bound under its own name, checks the correlation, prints the answer, exits non-zero for a tool that answered with an error or a module that never answered. ## 046 — an upstream image is copied between registries (ADR 0096) The builder reads the index and every manifest it names over the registry API (anonymous bearer token on challenge), moves each blob by digest into the mesh's registry, puts the manifests and then the index under the module's repository, and pins the index. Genesis keeps the pull. Tested against a fake upstream serving an index over two platforms and a fake mesh registry. ## 064 — a vendor image is a declared build input (ADR 0097) `build.on` takes `{arg, image@sha256:…}`; the image is copied in before the build and handed to the recipe. A `COPY --from` of an undeclared registry image is refused before the build; an undeclared `FROM` is said, not refused — the mesh's own images start FROM a public base, and refusing them refuses genesis. The package half of 064 stays open (needs a rerun). ## Proven `go test ./...` green with `MESH_TEST_POSTGRES`. Lab, against a controller image built from this branch: assigned-vault 4/4 with a two-secrets consumer (two values, two ledger holders, both rotated); assigned-tools-confluence green including an `ask` through the control plane that got the tool's answer.

jschoubben added 8 commits 2026-09-21 18:49:16 +00:00

A module may hold several secrets from one provider, each a pair of its own 6ae4ae1dba

secrets: maps a requirement to several files under local names. Each local name is
its own need, its own pair credential (the pair is keyed on it: migration 0027),
its own file on the consumer, its own holder at the provider (the identity with the
local name after it) and rotates apart from the others. The plain shape is
unchanged and every existing row is the credential it was (novox/hq 04-ISSUES/069,
ADR 0094).

ask: the control plane calls a module's tool and prints its answer 973cda5d76

A module serves tools under an account scoped to exactly that, and nothing else in
the mesh held an account that could ask one. The control plane does: ask publishes
on the RPC exchange with a private reply queue bound under its own name, checks the
correlation, prints the answer, and exits non-zero for a tool that answered with an
error or a module that never answered (novox/hq 04-ISSUES/049, ADR 0095).

Several secrets expand where the consumer is known, not on the first module to mention the provision 76773dfbf5

The lab's two-secrets consumer was given one credential and no file: the expansion
ran on the resolver's walk over names, on whichever module mentioned the provision
first, and the per-consumer pass copied that. It expands in that pass now, and a
test has two consumers of one provision, one keeping one file and one keeping two.

A need is kept once per provision, consumer, local name and provider 3e5c010c5e

Two consumers of one same-node provision produced two raw needs and, fanned out per
consumer, four — the same credential twice for each. Harmless, since a pair is one
row however often it is asked for, and wrong all the same.

A provider keeps one grant file per holder, with the local name in its id and path 5049d201c6

The lab's vault refused a declaration naming two files with one identity: the
two secrets of one consumer. The holder's suffix is in the resource id and the path now.

An upstream image is copied between registries, never through a machine's image store 412599de9a

A published image is an index over several architectures; pulled, the runtime's
store keeps the index and refuses to push one platform out of it. The builder now
reads the index and every manifest it names over the registry API, with the
anonymous bearer token the public hub hands out, moves each blob by digest into the
mesh's registry, puts the manifests and then the index under the module's repository,
and pins the index. Genesis, with no registry to copy into, keeps the pull
(novox/hq 04-ISSUES/046, ADR 0096).

A build declares the vendor image it stands on, and a recipe fetches nothing undeclared 6f6e1244d4

build.on takes {arg, image@sha256:…} beside {arg, module, artifact}: the image is
copied into the mesh's registry before the build (ADR 0096) and the recipe reads the
copy from the argument. A FROM or COPY --from naming a registry image the manifest
did not declare is refused before the build, naming it and the remedy; stages,
declared arguments and scratch are not fetches (novox/hq 04-ISSUES/064, ADR 0097).

An undeclared COPY --from is refused; an undeclared FROM is said, not yet refused e81f352979

The mesh's own images start FROM a public base — the control plane's, the builder's,
the tool runtime's — and refusing those refuses genesis. They declare their bases
next; until then the base is named every build, with the remedy.

jschoubben added 1 commit 2026-09-21 19:03:24 +00:00

Review: one local name is still a local name; a local name is unique; recovery knows it; recipes read as instructions; a tag before a digest; ask fails at once when nothing serves 9f3790dcda

A secrets object with one local name delivered no file. Two requirements could share
a local name. secret recover and the export could not tell two locals apart. The
recipe check missed continued lines and read heredoc bodies as bases. repo:tag@digest
kept the tag in the repository. ask now publishes mandatory, so a tool nothing serves
is said at once rather than after the wait.

jschoubben merged commit d7dab9c09f into main

2026-09-21 19:05:11 +00:00

jschoubben deleted branch multiple-fixes

2026-09-21 19:05:12 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-controller#38