GBrain Files

A write that deduplication redirects onto an existing page is now checked against the write scope of whoever asked for it. When the same content arrives under a new slug, gbrain recognises it and points the write at the page that already holds it. That redirected target is now tested against the caller's own scope — under whichever mechanism confines that caller. One of the two mechanisms was consulted at that point; both are now.

Nothing changes for local CLI use, or for clients that hold unrestricted write access — neither was ever scope-confined. A confined caller whose write dedups onto a page inside its own scope keeps working exactly as before; that redirect is a feature and it is preserved, with a regression test to keep it that way. A confined caller whose write dedups onto a page outside its scope now gets permission_denied, with the remedy in the message: drop the id: frontmatter field, or change the content, to write a new page under your own prefix. The denial does not name the page the write resolved to.

Recommended for any brain served over HTTP to scope-restricted clients.

To take advantage of v0.42.73.2

:::bash
gbrain upgrade

Nothing to configure. Existing clients keep their scopes unchanged, and no re-registration is needed.

For contributors

Reported privately by an external security researcher, who supplied a fix and a regression test with it. The version that shipped composes the two existing scope-matching rules into a single predicate rather than restating either one, so the check at the door and the check after a redirect cannot drift apart; the audit the report prompted closed the same gap on one further caller path.