Repository navigation
Accept the tokens that SDK 0.1.0 signs: SDK sub claims and org-wide tokens without a repo claim #658
Description
Problem
The stable SDKs 0.1.0 (Go github.com/pierrecomputer/sdk/go v0.1.0, npm @pierre/sdk 0.1.0, PyPI pierre-sdk 0.1.0) sign their own request tokens by default (PIERRE_PRIVATE_KEY or option.WithPrivateKey). open.storage rejects those tokens for two reasons:
subclaim. The SDKs setsubtopierre-sdk-go,pierre-sdk-pythonorpierre-sdk-typescript(go/internal/credentials/credentials.goSubject,python/src/pierre/_credentials.pySUBJECT,typescript/dist/runtime/credentials.jsSUBJECT, all at taggo/v0.1.0).internal/auth/verifier.gorequiressub == "@pierre/storage"and answers401 invalid tokenotherwise. The vendored upstream guide (docs/upstream/getting-started/authentication.md) describessubas an agent identity "for logging", for exampleci-pipeline-prod.- Org-wide tokens. For
meta.getandrepos.listthe SDKs omit therepoclaim (repo,omitempty; the upstream guide says "omit for org-wide tokens"). open.storage requiresrepo: "org"and answers403 token is not org-scoped.
So with the default credential path, every one of the 39 SDK 0.1.0 operations fails against open.storage, even after #656 adds the missing routes. Tokens from openstorage mint or from SDK 1.17.1 (@pierre/storage, sub: "@pierre/storage", repo: "org") still work, through option.WithToken or option.WithGetToken.
Evidence
I found this while dogfooding #656 on a local node (verify-openstorage skill, branch sdk-canonical-routes-issue656), with the SDK's own signer (auth.CreateToken with the node's org key) and only the claims below changed:
sub |
repo for org-wide ops |
meta.get |
repos.create |
|---|---|---|---|
SDK default (pierre-sdk-go) |
omitted (SDK default) | 401 invalid token | 401 invalid token |
@pierre/storage |
omitted (SDK default) | 403 token is not org-scoped | OK |
@pierre/storage |
org |
OK | OK |
Desk decision needed
This changes token verification (docs/reference/authentication.md), so it needs a decision before code. Options I see:
- Option A: accept any non-empty
sub, and treat a token without arepoclaim as org-wide (only org-level routes accept it; repo-scoped routes keep requiring a matchingrepo). - Option B: also accept the three SDK subjects next to
@pierre/storage, and accept an omittedrepoas org-wide.
Severity
High: the documented default credential path of every stable upstream SDK cannot call open.storage.
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high
Activity
ThomasK33 commentedon Nov 4, 2026
Desk decision: Option A.
sub. The vendored upstream guide (docs/upstream/getting-started/authentication.md:23) callssuban "Agent identity (for logging)" and its examples useci-pipeline-prod. Authorization stays with the signature,iss,exp,scopesandrepo. An empty or missingsubstays a 401.repoclaim as org-wide, as the guide says ("omit for org-wide tokens"). It must behave exactly likerepo: "org"does today: org-level routes accept it, and repo-scoped routes refuse it the same way they refuserepo: "org". Widen repo access only if the vendored spec documents it, and then in a separate PR.sub: "@pierre/storage"inopenstorage mint, so older verifiers keep accepting our tokens.This changes token verification, so the PR gets a full Codex security review on its exact head. Every place that reads
sub(logs,internal/githttp/server.go, metrics) must still be safe with an arbitrary string: bounded length in logs, no use as a key without escaping.An owner workspace will implement it.
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:medium