feat(credentials): re-key team vaults, and reach sh1pt's vault as a fifth provider

[ralyodio]

Two additions to Credential Sharing: vault re-keying, and the sh1pt provider adapter.

logicsrc credentials rotate — re-key only

logicsrc credentials rotate acme web prod            # dry run (default)
logicsrc credentials rotate acme web prod --approve
logicsrc secrets rotate acme --approve               # every vault you can open

Fresh DEK, re-sealed to the members who keep access, every secret re-encrypted under it. Values do not change — nothing that consumes them breaks. What changes is that every wrapped key issued before now is dead, so a kept copy of an old grant buys nothing.

flag	who keeps access
--active (default)	only members whose team status is active and who hold a grant today — the "someone left" rotation; everyone else is revoked
--all	everyone holding a grant today, whatever their status — hygiene, no revocation

Why it commits atomically

The DEK is recoverable only through the grants. A half-applied rotation — new grants over old ciphertext, or the reverse — leaves a vault no one can ever read again. So the client computes the entire next state and the server commits it in one transaction (new db.batch helper).

Guards, all enforced rather than documented:

• Every submitted fingerprint must equal the stored one. The server cannot see values, but it can prove a re-key didn't swap any.
• A rotation that would leave the caller ungranted, grant nobody, or cover the wrong number of secrets is rejected before any write.
• Client-side, a secret that fails to decrypt aborts the whole plan rather than being dropped — dropping it would destroy it on write.

Two fixes fell out along the way: GET /vaults/:id/grants now returns publicKey and status so a client re-seals in one pass instead of N+1 user lookups, and revocation now deletes the grant row. Previously there was no revoke path at all, so a stale row kept reporting access it no longer conferred.

sh1pt as the fifth provider

sh1pt's vault holds delivery credentials the other four generally don't — App Store Connect keys, Play service accounts, npm/Docker/Cloudflare tokens.

It's the only adapter driven through a CLI rather than HTTP, because sh1pt publishes sh1pt secret set|get|list|rm as the interface to its vault and documents no REST endpoint. Two consequences:

• Values go over the child's stdin, never argv. A secret in argv is readable by any user on the host via ps for the life of the call. There's a test asserting the value never appears in argv.
• sh1pt secret get requires interactive confirmation, so it can't be scripted. The adapter is therefore write-only for values (readValues: false) exactly like github-secrets: a sync target, never a source, no value-restoring rollback.

docs/credential-sharing.md says LogicSRC "does not call out to product-specific commands." I've written the exception into the spec rather than leave it contradicted: a transport choice inside an adapter is the layer where product-specific I/O belongs, and it doesn't move those commands into the core contract. Worth a look if you disagree with that reading.

Verification

suite	result
@logicsrc/plugin-credential-sharing	35 passed (17 new)
@logicsrc/cli	44 passed
@logicsrc/pwa	21 passed (8 new, real in-memory libSQL)
@logicsrc/web contract	71 passed

@logicsrc/cli and @logicsrc/web both build clean.

The crypto tests assert the properties that actually matter, not just that the code runs: the old DEK fails to decrypt rotated ciphertext, and a departed member's stale grant opens a key that no longer works. The sh1pt tests drive a real fake sh1pt binary rather than a mocked execFile — which is how a hang surfaced: with nothing to pipe, stdin was left open and any subcommand reading it would wait forever. Fixed to always close.

Worth your judgement

• --active / --all semantics. Your sketch had --all (--active default) on one axis. There's no active/inactive concept on secrets in the schema, but credshare_members.status is active | invited, so I read the axis as who keeps the key. Vault selection is positional instead (rotate <team> [project] [env]). Say the word if you meant something else.
• The sh1pt CLI flag names. --project / --env scoping is inferred from the other adapters' endpoint model; sh1pt's public docs don't show its scoping flags. Worth confirming against the real binary before this ships — I had no sh1pt on PATH to check.

🤖 Generated with Claude Code

[github-actions]

vu1nz Security Review

0 finding(s) in PR #?

No security issues found.