Version Packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@cipherstash/stack-prisma@1.2.0

Minor Changes

• ba37039: Move the bundled EQL v3 migrations to eql-3.0.5, which renames the SQL
  function eql_v3.ste_vec_contains to eql_v3.jsonb_document_contains.

  The blast radius is narrower than a renamed public function suggests. The
  @> / <@ operators on public.eql_v3_json_search behave exactly as before,
  and so do the two function-form entry points that exist for platforms without
  operator support — eql_v3.jsonb_contains(jsonb, jsonb) and
  eql_v3.jsonb_contained_by(jsonb, jsonb) are byte-identical to 3.0.4. Those
  are what a PostgREST caller invokes, so PostgREST callers on the documented
  surface are not affected. The renamed function is the typed implementation
  those operators dispatch into.

  And the old name still works. eql-3.0.5 ships eql_v3.ste_vec_contains as
  a deprecated delegating alias for both overloads, so hand-written SQL naming it
  — an application query, a view, an RLS policy, or a per-function
  GRANT EXECUTE ON FUNCTION eql_v3.ste_vec_contains(…) — keeps resolving. The
  typed overload stays inlinable, so a function-form query through the alias
  still matches the same functional GIN index. Migrate to
  jsonb_document_contains when convenient; nothing forces it at upgrade time.

  Separately — and true of every EQL upgrade, not just this one: the install
  bundle opens with DROP SCHEMA IF EXISTS eql_v3 CASCADE, so applying it drops
  every object in eql_v3 / eql_v3_internal and everything that depended on
  them. Encrypted data and column types are not affected — the storage
  domains are public.eql_v3_*, deliberately outside both dropped schemas, and
  their CHECK functions are re-created rather than dropped. What does not survive
  is everything else pointing into the schema, which is two actions, neither of
  them to do with the rename:

  1. Re-run your grant script. Every grant on every eql_v3 /
     eql_v3_internal object is gone. The schema-wide form EQL documents —
     GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA eql_v3 TO app_role — picks up
     both the new name and the alias on its own.
  2. Recreate your functional indexes, then ANALYZE. Indexes over
     eql_v3.eq_term(…) / ord_term / match_term / to_ste_vec_query(…)
     depend on the dropped schema and go with it. Nothing errors afterwards:
     encrypted predicates keep working and silently fall back to sequential
     scans. A migration runner will not redo an already-applied migration, so
     this has to be a new one. The stash-indexing skill documents the
     mechanism ("These indexes do not survive an EQL reinstall or upgrade") and
     the EXPLAIN check that confirms recovery; capturing and restoring them
     automatically is tracked in
     cipherstash/stack#918.

  Any RLS policy, view, or constraint that calls an eql_v3 function is dropped
  by the same CASCADE and needs recreating too. The rename itself needs no
  action — the alias makes it non-breaking.

  Two artefacts carry the new bundle:

  • A new upgrade edge, 20260814T0000_upgrade_eql_v3_3_0_5, carrying the
    invariant cipherstash:upgrade-eql-v3-bundle-3.0.5-v1. Databases already
    running an earlier bundle re-install through this edge on the next
    prisma-next migration plan followed by prisma-next migrate, exactly as
    they did for 3.0.2 and 3.0.4. migrate alone is not enough — the seed
    phase that copies a new migration package into your repo runs only from
    migration plan, so without it the 3.0.5 directory never reaches disk and
    migrate is a silent no-op that leaves the database on the older bundle.
  • The baseline install migration 20260601T0100_install_eql_v3_bundle, whose
    baked bundle moves to 3.0.5 and which gains a fourth no-SQL carrier op for
    the new invariant. Fresh databases therefore land on 3.0.5 from the single
    all-additive genesis edge, keeping db init (additive-only policy) working.

  Action required. The baseline's bytes — and so its migrationHash — have
  changed. If your project already has a migrations/cipherstash/ directory
  generated against @cipherstash/stack-prisma@1.0.0 or @1.1.0, delete that
  directory and re-run prisma-next migration plan (or migrate); the 1.1.0
  Prisma Next 0.17 upgrade re-anchored the same artefacts, so a space vendored
  against either release is stale here. The seed phase regenerates
  it byte-identical to the shipped artefacts. Your database keeps its markers, so
  already-applied invariants are not re-run — the only new work is the 3.0.5
  upgrade edge.

  If you skip the delete, nothing warns you: a vendored baseline is stale but
  internally intact, so it passes every integrity check. On an existing database
  the upgrade still applies correctly; on a fresh one, db init refuses with
  Operation cipherstash.upgrade-eql-v3-bundle-3.0.5 has class "data" which is not allowed by policy. — an error that names neither the directory nor the
  remedy. See "Upgrading from 1.0.0" in the package README.

  Why the baseline was re-emitted rather than left frozen. These artefacts are
  content-addressed and normally append-only: an EQL bump ships as a new upgrade
  directory and published directories are never rewritten. That rule cannot be
  followed here without a second from: null genesis edge, because no upgrade
  edge can ever be walked by db init — every upgrade edge is a self-edge, and
  the integrity checker requires a self-edge to carry a data-class op, which
  db init's additive-only policy refuses. A fresh database must therefore
  collect every head-ref invariant from the genesis edge it walks. The
  append-only alternative would duplicate the full ~2.6 MB bundle into a new
  genesis edge on every EQL release, permanently; re-emitting was taken instead
  while 1.0.0 was two weeks old with negligible adoption, and is a decision to be
  re-argued on adoption numbers rather than repeated by default.

Patch Changes

• 4422d5c: Pin the packed @cipherstash/eql dependency to an exact version, closing a
  route by which an installed EQL bundle could drift ahead of the code built
  against it.

  Both packages declared "@cipherstash/eql": "workspace:^" under
  dependencies. In this workspace that resolves in-tree either way, so nothing
  in development or CI could see a difference — but the two specifiers do not
  pack the same. pnpm rewrites the protocol when it builds the tarball a customer
  actually installs:

  "workspace:^"  packs as  "^3.0.5"
  "workspace:*"  packs as  "3.0.5"
  

  The caret is the problem. @cipherstash/eql is still published from
  cipherstash/encrypt-query-language until the publisher repoint, so a 3.0.x can
  reach npm without passing through this repository at all — and ^3.0.5 accepts
  it. A customer installing stash or @cipherstash/stack-prisma would then get
  SQL that STORES and queries encrypted payloads at one version, while
  @cipherstash/stack's v3 domain types (which EMIT those payloads) and
  stack-prisma's baked migrations stayed frozen at the version this repo built
  and tested against. The two halves of EQL are released in lockstep precisely
  because that skew does not fail at install or in CI — it fails in a database.

  workspace:* is the only form that closes it. A literal "3.0.5" would be an
  exact pin too, but it is a registry pin: pnpm run lint:eql-pins rejects it,
  because resolving EQL from a registry rather than from this repo is the same
  drift one layer up.

  No API, behaviour or SQL changes. What changes is the dependency range in the
  published tarballs, and only in the narrowing direction — the version resolved
  today is the version that was already being resolved. Nothing needs to be done
  on upgrade.

  @cipherstash/stack declares the same dependency under devDependencies and
  is deliberately left alone: pnpm rewrites that range too, but no consumer of the
  package ever resolves it.

• c604028: Document the 1.0.0 → 3.0.5 upgrade in the package README: why
  migrations/cipherstash/ must be deleted and regenerated, what each Prisma Next
  command does if it is not, and the exact db init refusal
  (Operation cipherstash.upgrade-eql-v3-bundle-3.0.5 has class "data" which is not allowed by policy.) that a stale vendored directory produces on a fresh
  database.

  The behaviour worth knowing regardless of version: only prisma-next migration plan copies new migration packages into your repo. Running migrate or
  db init after upgrading this package without planning first silently leaves
  the database on the older EQL bundle — a stale vendored directory is internally
  intact, so it passes every integrity check and nothing reports a problem.

• Updated dependencies [e52d331]

  • @cipherstash/eql@3.0.6
  • @cipherstash/stack@1.2.0

stash@1.2.0

Patch Changes

• 801868d: Verify the EQL install SQL against its release digest before running it.

  stash eql install reads the EQL v3 bundle from the resolved
  @cipherstash/eql in your node_modules and executes it against your
  database. That read was a bare readFileSync — nothing checked that the bytes
  on disk were the bundle the resolved release actually ships. A corrupt,
  partially-updated, or tampered package installed silently: the database ended
  up carrying SQL the version it reports does not define, and the CLI printed
  "EQL extensions installed."

  The CLI now hashes the bundle and compares it to installSqlSha256 from the
  release manifest that ships alongside it, and refuses on a mismatch. The
  error names the expected digest, the actual digest, the resolved file path and
  the EQL version, so the remedy is visible rather than inferred. Verification
  happens before any database connection is opened, so a refusal means nothing
  was attempted — not that something was rolled back.

  The check covers all three paths that read the bundle: stash eql install,
  the SQL embedded by stash eql migration --drizzle / --supabase, and the
  expected-surface baseline stash eql verify compares your database against.
  @cipherstash/stack-prisma has verified against this same digest since its v3
  migrations landed; this brings the CLI in line.

  No healthy install is affected — the SQL and its manifest are produced by the
  same build of @cipherstash/eql, so a mismatch only ever means a broken
  dependency tree.

  skills/stash-cli documents the new pre-flight alongside the existing
  post-install surface check, so an agent reading it does not report a digest
  refusal as a failed install.

• 4422d5c: Pin the packed @cipherstash/eql dependency to an exact version, closing a
  route by which an installed EQL bundle could drift ahead of the code built
  against it.

  Both packages declared "@cipherstash/eql": "workspace:^" under
  dependencies. In this workspace that resolves in-tree either way, so nothing
  in development or CI could see a difference — but the two specifiers do not
  pack the same. pnpm rewrites the protocol when it builds the tarball a customer
  actually installs:

  "workspace:^"  packs as  "^3.0.5"
  "workspace:*"  packs as  "3.0.5"
  

  The caret is the problem. @cipherstash/eql is still published from
  cipherstash/encrypt-query-language until the publisher repoint, so a 3.0.x can
  reach npm without passing through this repository at all — and ^3.0.5 accepts
  it. A customer installing stash or @cipherstash/stack-prisma would then get
  SQL that STORES and queries encrypted payloads at one version, while
  @cipherstash/stack's v3 domain types (which EMIT those payloads) and
  stack-prisma's baked migrations stayed frozen at the version this repo built
  and tested against. The two halves of EQL are released in lockstep precisely
  because that skew does not fail at install or in CI — it fails in a database.

  workspace:* is the only form that closes it. A literal "3.0.5" would be an
  exact pin too, but it is a registry pin: pnpm run lint:eql-pins rejects it,
  because resolving EQL from a registry rather than from this repo is the same
  drift one layer up.

  No API, behaviour or SQL changes. What changes is the dependency range in the
  published tarballs, and only in the narrowing direction — the version resolved
  today is the version that was already being resolved. Nothing needs to be done
  on upgrade.

  @cipherstash/stack declares the same dependency under devDependencies and
  is deliberately left alone: pnpm rewrites that range too, but no consumer of the
  package ever resolves it.

• ad033df: skills/stash-prisma now documents the re-plan step that follows an
  @cipherstash/stack-prisma upgrade: rm -rf migrations/cipherstash && npx prisma-next migration plan, why only migration plan vendors new migration
  packages, and the exact db init refusal a stale vendored directory produces on
  a fresh database (Operation cipherstash.upgrade-eql-v3-bundle-3.0.5 has class "data" which is not allowed by policy.).

  The package README already carried this; the skill did not — and the skill is
  what ships inside the stash tarball and gets copied into a user's
  .claude/skills/, so an agent driving the upgrade hit the refusal with no route
  out of it. packages/stack-prisma/test/v3/stale-vendored-space.test.ts now pins
  both files to the planner's real message so they cannot drift apart again.

• 4422d5c: Correct two things the bundled agent skills were telling customers wrongly
  about EQL.

  skills/stash-postgres pointed at the wrong repository. EQL's source now
  lives in cipherstash/stack under packages/eql/, and that is where operator
  gaps and domain-level bugs are filed; only publishing still happens from
  cipherstash/encrypt-query-language, which the skill continues to say. The
  skill also cited "the EQL skill" as a source of truth that "ships from
  encrypt-query-language alongside the bundle" — no such skill ships from
  either repository, so the reference is gone and the remaining three sources
  (the generated types, the install SQL, and SELECT eql_v3.version()) are
  renumbered.

  And it claimed the CLI pins an exact @cipherstash/eql version, "so a
  database is only ever on one bundle." Neither half holds: the CLI depends on
  the workspace package rather than a pinned literal, and a database is on
  whatever bundle was last applied to it — the Prisma Next adapter installs and
  upgrades the bundle through its own migrations without involving the CLI at
  all. Replaced with the guarantee that does hold: one stash release carries
  one resolved bundle, and the database is the authority on which bundle it has.

  skills/stash-prisma hands out the functional-index recipe without saying an
  EQL upgrade destroys it. Installing a bundle begins with DROP SCHEMA IF EXISTS eql_v3 CASCADE, which cascade-drops every index over an eql_v3.*
  extractor — the PSL expression indexes Prisma Next 0.17 introduced and any
  rawSql index DDL alike; queries keep working and silently sequential-scan.
  Because an applied migration is never replayed, recovery is a NEW one: a PSL
  expression index has to change its name: (the physical name carries a content
  hash of the expression, so re-declaring the same one plans no work), and a
  rawSql recovery op needs a new id. Said where the recipe is given, pointing
  at stash-indexing for the mechanism and at
  cipherstash/stack#918 for
  capturing and restoring them automatically.

• ba37039: Update the bundled agent skills for eql-3.0.5. skills/stash-supabase
  re-states the PostgREST query-domain limitations against 3.0.5 (unchanged in
  substance — the typed eql_v3.query_* operand requirement still stands), and
  skills/stash-postgres drops one of the two places it claimed the CLI pins
  @cipherstash/eql to an exact version — a claim that stopped being true when
  EQL moved in-tree. The second copy goes in the same release, with the rest of
  that skill's EQL source and issue pointers.

• Updated dependencies [e52d331]

  • @cipherstash/eql@3.0.6
  • @cipherstash/migrate@1.0.0

@cipherstash/eql@3.0.6

Patch Changes

• e52d331: Point repository, repository.directory, and bugs.url at cipherstash/stack instead of the archived cipherstash/encrypt-query-language. Purely metadata — no behaviour change — but required before npm's trusted publishing (already repointed at cipherstash/stack) can accept a release: npm rejects a publish whose manifest repository.url doesn't match the publishing repository.

@cipherstash/protect-ffi@0.32.1

Patch Changes

• 4422d5c: Compile eql-bindings from this repository rather than from crates.io.

  The native binding pinned eql-bindings = "=3.0.2" from the registry. It now
  resolves by path from packages/eql/crates/eql-bindings, which ships at 3.0.5
  alongside the @cipherstash/eql SQL bundle.

  No behaviour change. eql-bindings is the Rust half of EQL — it EMITS the
  encrypted payloads that the SQL half STORES and queries — and its Rust source is
  byte-identical across 3.0.2, 3.0.4 and 3.0.5 (src/, bindings/ and schema/
  compared directly). What 3.0.3 through 3.0.5 changed was SQL, carried on the
  shared lockstep version number. So the payloads this binding produces are the
  same bytes before and after; what moves is the version stamped on the crate
  compiled into index.node, from 3.0.2 to 3.0.5.

  Why it is worth a release anyway. A registry pin let the two halves of EQL
  drift apart silently. Nothing asserted they agreed: a mismatched pair compiles,
  passes every suite, and fails in a database — because the failure is a payload
  the installed SQL cannot read, which no unit test holds both sides of. Resolving
  from the tree makes the skew unrepresentable: the emitter and the SQL are now
  the same commit, and pnpm run lint:eql-pins fails any change that reintroduces
  a registry pin on either.

  The flip was taken while it was a no-op deliberately. Waiting for the first
  release where the two halves genuinely diverge would have turned a provenance
  change into a behaviour change that had to be argued under credentialed test.

  Verified without credentials: cargo build -p protect-ffi clean, the crate test
  suite green (310 passed) with cargo fmt --check clean, and a
  wasm32-unknown-unknown build clean — the last of those being the target where a
  cross-workspace path dependency would break first, since the EQL workspace never
  otherwise builds for wasm32.

• Bump cipherstash-client, cts-common, stack-auth, and stack-profile to 0.42.2, which moves the transitive jsonwebtoken dependency from 9.3.1 to 10.4.0, resolving CVE-2026-25537 (a JWT claim-validation type-confusion bug that could allow bypassing nbf/exp checks). No API changes.

@cipherstash/stack@1.2.0

Patch Changes

• Updated dependencies [4422d5c]
• Updated dependencies
  • @cipherstash/protect-ffi@0.32.1

@cipherstash/stack-drizzle@1.2.0

Patch Changes

• @cipherstash/stack@1.2.0

@cipherstash/stack-supabase@1.2.0

Patch Changes

• @cipherstash/stack@1.2.0

@cipherstash/protect-ffi-darwin-arm64@0.32.1

@cipherstash/protect-ffi-darwin-x64@0.32.1

@cipherstash/protect-ffi-linux-arm64-gnu@0.32.1

@cipherstash/protect-ffi-linux-x64-gnu@0.32.1

@cipherstash/protect-ffi-linux-x64-musl@0.32.1

@cipherstash/protect-ffi-win32-x64-msvc@0.32.1

@cipherstash/wizard@1.2.0

@cipherstash/e2e@0.0.6

Patch Changes

• Updated dependencies [801868d]
• Updated dependencies [4422d5c]
• Updated dependencies [ad033df]
• Updated dependencies [4422d5c]
• Updated dependencies [ba37039]
  • stash@1.2.0
  • @cipherstash/stack@1.2.0
  • @cipherstash/wizard@1.2.0

@cipherstash/basic-example@1.2.17

Patch Changes

• @cipherstash/stack@1.2.0
• @cipherstash/stack-drizzle@1.2.0

@cipherstash/prisma-example@0.1.3

Patch Changes

• Updated dependencies [ba37039]
• Updated dependencies [4422d5c]
• Updated dependencies [c604028]
  • @cipherstash/stack-prisma@1.2.0
  • @cipherstash/stack@1.2.0

@cipherstash/bench@0.0.8

Patch Changes

• @cipherstash/stack@1.2.0
• @cipherstash/stack-drizzle@1.2.0

@cipherstash/test-kit@0.0.4

Patch Changes

• @cipherstash/stack@1.2.0