Skip to content

v10.5 — five auth fixes, no object versioning on encrypted buckets, and a settings drawer you can read on the light theme

Choose a tag to compare

@paracoding-ai paracoding-ai released this 19 Aug 11:59

Full release tree at commit cbe9a8b8 of the source repository, published by the product's own gh_commit reading each blob straight out of its own git store. MANIFEST.txt lists every file and its digest. 125 files, 27 of them executable.

Five authentication and authorisation fixes

Every one was re-measured against current code before it was touched, because the audit that found them was taken three releases earlier and a finding from a stale tree is a guess.

The agent-card route served a HIDDEN strain's full card to an anonymous caller. The roster listing already filtered hidden strains; this route did not, which made hidden a listing preference rather than an access control. It now answers 404 with the same body as an absent or inactive strain, so a prober cannot tell "hidden" from "does not exist" by response shape.

The console session check called the IAP-identity helper without the audience guard its two sibling call sites both apply. install.sh sets the audience variable, so this is defence in depth for a hand-rolled deploy rather than a live hole — but it was the one site that dropped a check its siblings keep, on the function guarding the most.

The queue-claim route filtered work items by a client-supplied role while recording the server-resolved caller as the claimant, and never compared the two. Any holder of a valid agent token could claim another role's queued work. It now refuses with 403 rather than silently substituting the resolved identity, so a mismatch is visible instead of quietly reassigned.

Session enforcement defaulted OFF in code and ON in the installer. Inverting the code default is a no-op for every installed system; it closes the gap on a hand-rolled deploy that omitted the variable, where "unset" silently meant "never deny".

The default role for an unbound OAuth connector was seeded with no tool classes, which this system resolves as EVERY class — including privileged staging — for an identity nobody has bound to a human yet. New installs now seed it read-only. Note for existing installs: the seeder returns early unless the strain collection is empty, so this does NOT retro-fix a running fleet. Check that role yourself.

Unchanged, and now commented rather than quietly load-bearing: the wildcard CORS header on both surfaces is safe ONLY because credentials are never allowed, so a browser withholds the session and IAP cookies cross-origin. Adding a credentials flag to that middleware would make every cookie-authenticated console route readable cross-origin.

No object versioning on the buckets this installs

install.sh now asserts --no-versioning on the data lake, the git object store and the exec-records bucket, alongside public access prevention and uniform bucket-level access.

Every object this system writes to those buckets is encrypted at rest, so a retained noncurrent generation is ciphertext, not a backup: unreadable once the vault epoch moves, silently holding bytes that were meant to be replaced, and billed for the whole time it sits there. It buys least of all on the git object store, where blobs are content-addressed — a write either creates a name that did not exist, or rewrites a name with byte-identical content, so there is no earlier version to keep. History is in the objects. Git is the rollback.

It is asserted, not merely omitted, and on an existing install that is the whole change: dropping the flag would only stop the installer turning versioning ON and would do nothing to a bucket that already has it. Suspending it is not destructive — generations already retained stay retained.

Two refusal messages in the work runner told you to recover a damaged encrypted object "from object versioning", one of them printing the gcloud command to do it with. On a bucket without versions that command returns the single live object and you conclude the restore worked. Both now say there is nothing to restore from, and to report it and stop.

The settings drawer is legible on the light theme

The drawer paints its own surface in colour literals but reads the theme's ink token for text, so the light palette added in 10.3 rendered near-black text on a near-black drawer. It is the drawer you open to CHANGE the theme, so the one control that gets you back out of a theme you did not like was the one that theme broke. The effective dark set is now pinned on that element: a custom property on a nearer ancestor wins by inheritance, so it holds without !important and without touching any palette.

The plugin manifest no longer claims a gate that is not in the path

agent-plugin/plugin.json said "No privileged action runs without a WebAuthn approval on your own device." install.sh ships PC_AUTO_APPROVE=1, PC_GUARDRAILS=0 and PC_REQUIRE_PASSKEY=0, so a job an agent stages is signed and executed in the same call. SECURITY.md was already honest about all three; the plugin manifest — the file you read BEFORE installing anything — was the one contradicting it. It now says what happens and names the one setting that stops it.


Apache-2.0. Your project, your bill, your key.