Issue 100: a secret the mesh mints cannot be the one the service it takes over already uses #86

2026-09-23T00:54:17Z

jschoubben commented

2026-09-23 00:54:17 +00:00

Found at the second cutover. The service signs its sessions with a secret the machine has had for as long as it has been running; the module declares that secret as one it requires, so the mesh minted a new one.

Carrying the old value in — secret accept, which exists for values "the mesh did not make and cannot invent" — works only for a module's own secrets. A secret answered by the provision is minted, and there is no way to say this one already exists, here it is. The two look the same in a manifest and behave oppositely at a cutover.

Here it cost one re-login. Six catalogue modules take a secret this way, and the failure differs: a service whose setup already ran ignores the value (the mesh then holds a credential that does not work and believes it is the admin's); a credential other systems were configured with changes under them; and a secret that keys stored data would make that data unreadable — none of the six is in that class, and nothing would stop one being added.

None of it is reported. The cutover succeeds, the service answers, and the damage is at a distance.

Found at the second cutover. The service signs its sessions with a secret the machine has had for as long as it has been running; the module declares that secret as one it *requires*, so the mesh minted a new one. Carrying the old value in — `secret accept`, which exists for values "the mesh did not make and cannot invent" — works only for a module's **own** secrets. A secret answered by the provision is minted, and there is no way to say *this one already exists, here it is*. The two look the same in a manifest and behave oppositely at a cutover. Here it cost one re-login. Six catalogue modules take a secret this way, and the failure differs: a service whose setup already ran ignores the value (the mesh then holds a credential that does not work and believes it is the admin's); a credential other systems were configured with changes under them; and a secret that keys stored data would make that data unreadable — none of the six is in that class, and nothing would stop one being added. None of it is reported. The cutover succeeds, the service answers, and the damage is at a distance.

jschoubben added 1 commit 2026-09-23 00:54:18 +00:00

Issue 100: a minted secret cannot be the one the service already uses 157c6edd50

Found at the second cutover. Carrying a value in works only for a module's own
secrets; a secret answered by the provision is minted, and six catalogue modules
take one that way.

jschoubben merged commit f4f58e7c30 into main

2026-09-23 00:54:22 +00:00

jschoubben deleted branch issues/100-a-minted-secret-cannot-be-the-one-the-service-already-uses

2026-09-23 00:54:22 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#86