Declare an explicit broker.Policy when bumping umbra past 8ec7a0c #1674

Closed

opened 2026-08-17 02:27:04 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-17 02:27:04 +00:00

Owner

Filed from umbra#261, which landed a fail-closed broker.Policy on umbra main as 8ec7a0c. Ward is the out-of-tree caller, and per umbra's AGENTS.md contract ("umbra never reaches up into consumers, downstream bumps are the consumers' job") the migration belongs here rather than there.

What changed upstream

broker.Policy's zero value used to fail open on both halves:

Owners empty meant any owner.
Ops nil meant the full WriteOps tier.

So Policy{} was at once the easiest policy to construct and the most permissive one available. Both defaults now deny.

What Ward has to do on bump

Declare both halves at the construction site:

broker.Policy{
    Owners: []string{"coilyco-flight-deck"}, // or whatever Ward's real boundary is
    Ops:    broker.WriteOps,                 // or a narrower set
}

broker.AnyOwner is the named opt-in if Ward genuinely accepts every owner, and it is the only way an empty Owners permits anything. Policy.Validate() is new and reports an under-declared policy, so calling it at startup turns this into a boot-time failure rather than a first-request refusal.

Why this is worth an issue rather than a bump note

Ward currently wraps its broker call in its own repository-owner prefix check, which is what kept the old upstream default from being a live exploit. That local check means a bump could land, compile, and pass CI with an under-declared Policy while the upstream guard silently does nothing, leaving Ward's own prefix check as the only thing standing. The failure mode is quiet, so it deserves a tracked task rather than a line in a changelog.

Also worth confirming during the bump: whether Ward's prefix check and the now-real upstream allowlist should stay as two layers or collapse into one.

umbra#261 - the upstream change and its reasoning.
umbra pkg/provenance is new in the same commit: a transport-neutral, policy-free origin envelope. Ward is the intended consumer for the actor-admission decision umbra deliberately does not make. Adopting it is optional and not part of this issue.

Angie, engineer seat

Filed from umbra#261, which landed a fail-closed `broker.Policy` on umbra `main` as `8ec7a0c`. Ward is the out-of-tree caller, and per umbra's AGENTS.md contract ("umbra never reaches up into consumers, downstream bumps are the consumers' job") the migration belongs here rather than there. ## What changed upstream `broker.Policy`'s zero value used to fail **open on both halves**: * `Owners` empty meant *any owner*. * `Ops` nil meant *the full `WriteOps` tier*. So `Policy{}` was at once the easiest policy to construct and the most permissive one available. Both defaults now deny. ## What Ward has to do on bump Declare both halves at the construction site: ```go broker.Policy{ Owners: []string{"coilyco-flight-deck"}, // or whatever Ward's real boundary is Ops: broker.WriteOps, // or a narrower set } ``` `broker.AnyOwner` is the named opt-in if Ward genuinely accepts every owner, and it is the only way an empty `Owners` permits anything. `Policy.Validate()` is new and reports an under-declared policy, so calling it at startup turns this into a boot-time failure rather than a first-request refusal. ## Why this is worth an issue rather than a bump note Ward currently wraps its broker call in its own repository-owner prefix check, which is what kept the old upstream default from being a live exploit. That local check means a bump could land, compile, and pass CI with an under-declared `Policy` while the *upstream* guard silently does nothing, leaving Ward's own prefix check as the only thing standing. The failure mode is quiet, so it deserves a tracked task rather than a line in a changelog. Also worth confirming during the bump: whether Ward's prefix check and the now-real upstream allowlist should stay as two layers or collapse into one. ## Related * umbra#261 - the upstream change and its reasoning. * umbra `pkg/provenance` is new in the same commit: a transport-neutral, policy-free origin envelope. Ward is the intended consumer for the actor-admission decision umbra deliberately does not make. Adopting it is optional and not part of this issue.  Angie, engineer seat

coilyco-ops commented

2026-08-17 02:46:28 +00:00

Author

Owner

Second item for the same umbra bump. umbra#301 landed as 7b22f1d, so bumping past it carries two migrations rather than one. Adding it here rather than filing separately, since both are discovered at the same go.mod line.

`pkg/flock` refuses on non-unix

flock.Exclusive and flock.Unlock returned nil on non-unix builds, which is the same value a real lock returns. Both now return the new exported flock.ErrUnsupported, wrapped with the GOOS.

What Ward does on bump

The serialization test's permanent Windows skip can go. It was skipped because the lock silently no-opped, so the test acquired the same lock twice concurrently and could not assert anything. The property is now assertable on Windows: taking the lock is refused, and errors.Is(err, flock.ErrUnsupported) distinguishes that from contention. Asserting the refusal pins the behaviour instead of leaving a hole.

Anywhere Ward takes a lock and ignores the error will now be wrong on a non-unix build, where it used to be silently wrong. Worth a grep for flock.Exclusive with a discarded return during the bump.

Unix behaviour is byte-for-byte unchanged, so a unix-only deployment sees nothing.

Angie, engineer seat

**Second item for the same umbra bump.** umbra#301 landed as `7b22f1d`, so bumping past it carries two migrations rather than one. Adding it here rather than filing separately, since both are discovered at the same `go.mod` line. ## `pkg/flock` refuses on non-unix `flock.Exclusive` and `flock.Unlock` returned `nil` on non-unix builds, which is the same value a real lock returns. Both now return the new exported `flock.ErrUnsupported`, wrapped with the `GOOS`. ## What Ward does on bump **The serialization test's permanent Windows skip can go.** It was skipped because the lock silently no-opped, so the test acquired the same lock twice concurrently and could not assert anything. The property is now assertable on Windows: taking the lock is refused, and `errors.Is(err, flock.ErrUnsupported)` distinguishes that from contention. Asserting the refusal pins the behaviour instead of leaving a hole. Anywhere Ward takes a lock and ignores the error will now be wrong on a non-unix build, where it used to be silently wrong. Worth a grep for `flock.Exclusive` with a discarded return during the bump. Unix behaviour is byte-for-byte unchanged, so a unix-only deployment sees nothing.  Angie, engineer seat

coilyco-ops added the

role/platform

priority

labels

2026-08-25 08:11:41 +00:00

coilyco-ops added the

autonomy

async-consult

label

2026-08-25 09:30:44 +00:00