swarm-bao: the CN-collision comments describe a hazard that is now guarded
Both places that warned about a hive named after the controller's cert-auth
subject still told the reader it was unmitigated, and the option's description
recommended a migration — "change this to something outside the hive-name
grammar, at the cost of a role rename in any store that has already run the
granting unit" — that is no longer the answer and is not cheap.
swarm.nix now feeds the subject into the guard on `swarm.hives`, so a
colliding roster fails evaluation. Both paragraphs get SHORTER saying so: a
guarded hazard needs the consequence ("reserved as a hive name") rather than
the threat model, and the write-site keeps only the sentence the next person
needs — a role added beside this one must join that list.
Found by sweeping for the claim rather than for the symbol: the change that
made these stale touched swarm.nix, swarm-otel.nix and module-eval.nix, so no
diff-context or doc-comment rule covers a paragraph two files away. Grepping
the tree for "would satisfy" and for prose about a hive named after a subject
turned up exactly these two and nothing in docs/.
This commit is contained in:
parent
1176de08bd
commit
f1e0d9c20e
1 changed files with 7 additions and 9 deletions
|
|
@ -547,11 +547,10 @@ in
|
|||
writes — not a credential belonging to the controller. Nothing outside
|
||||
the store needs it except whatever issues that leaf.
|
||||
|
||||
⚠️ The CA this role trusts also signs each hive's reader leaf, whose CN
|
||||
is the hive's own name, so a hive named `swarm-controller` would satisfy
|
||||
the role. Changing this to something outside the hive-name grammar
|
||||
(`[a-z0-9-]`) rules that out — at the cost of a role rename in any store
|
||||
that has already run the granting unit.
|
||||
⚠️ Reserved as a hive name. A hive's own leaf carries its name as the
|
||||
CN, so a hive named after this subject would satisfy the role —
|
||||
./swarm.nix feeds this value into the guard on
|
||||
{option}`services.hyperhive.swarm.hives` to make that unrepresentable.
|
||||
'';
|
||||
};
|
||||
|
||||
|
|
@ -947,10 +946,9 @@ in
|
|||
esac
|
||||
|
||||
# `certificate=` is the CA, so this role trusts every leaf that
|
||||
# CA signed and `allowed_common_names` is the whole of what
|
||||
# narrows it to one identity. ⚠️ The same CA signs each hive's
|
||||
# reader leaf with CN = the hive's name, so a hive named
|
||||
# `${controllerCn}` would satisfy this role.
|
||||
# CA signed and `allowed_common_names` is the whole narrowing —
|
||||
# which is why ./swarm.nix reserves this subject as a hive name,
|
||||
# and why a role added beside this one must join that list.
|
||||
#
|
||||
# Named outside the `hive-*` namespace the policy grants, so the
|
||||
# controller cannot rewrite the role that constrains it.
|
||||
|
|
|
|||
Loading…
Reference in a new issue