Skip to content

fix(cedar): align cedarpy and cedar-wasm to same Rust core (4.8.2) #168

@scottschreckengaust

Description

@scottschreckengaust

Summary

Align both Cedar policy engine bindings to the same underlying Rust core version (4.8.2) for true cross-engine parity. Currently there is a pre-existing 2-minor-version gap.

Current state (verified from source Cargo.toml files)

Package Current pin Cedar Rust core Source
cedarpy 4.8.0 4.8.2 k9securityio/cedar-py v4.8.0 Cargo.toml
@cedar-policy/cedar-wasm 4.10.0 4.10.0 cedar-policy/cedar v4.10.0 cedar-wasm/Cargo.toml

Gap: Python agent evaluates Cedar policies on Rust 4.8.2; TypeScript Lambda handlers evaluate on Rust 4.10.0. The contracts/cedar-parity/ golden fixtures validate that for our specific policies/inputs the results agree — but this is "tested-compatible," not "guaranteed identical."

Target state

Package Target pin Cedar Rust core
cedarpy 4.8.3 4.8.2
@cedar-policy/cedar-wasm 4.8.2 4.8.2

Both bindings on Cedar Rust 4.8.2 = true engine parity.

Why 4.8.2 (not 4.10.0 or 4.11.0)?

No cedarpy version wraps Cedar Rust 4.9+. The latest cedarpy (4.8.3, published 2026-05-14) still pins cedar-policy = "4.8.2" in its Cargo.toml. Until k9securityio publishes a cedarpy that wraps a newer Rust core, we must anchor to 4.8.2.

Deliverables

  • Bump cedarpy from 4.8.0 to 4.8.3 in agent/pyproject.toml
  • Downgrade @cedar-policy/cedar-wasm from 4.10.0 to 4.8.2 in cdk/package.json
  • Downgrade @cedar-policy/cedar-wasm from 4.10.0 to 4.8.2 in cdk/layers/cedar-wasm/package.json
  • Update the comment in agent/pyproject.toml to accurately say: parity with @cedar-policy/cedar-wasm@4.8.2 (both Cedar Rust 4.8.2)
  • Update the _cedar_parity_pin field in cdk/package.json to reference the correct versions
  • Regenerate lockfiles: uv lock (agent) + yarn install (root)
  • Run parity fixtures: agent/tests/test_cedar_parity.py + cdk/test/handlers/shared/cedar-parity.test.ts
  • Refresh parity fixture expected values if any diverge (they shouldn't — same Rust core)
  • Add Dependabot ignore rules for both cedar packages in .github/dependabot.yml:
    # Under uv section:
    ignore:
      - dependency-name: "cedarpy"
        update-types: ["version-update:semver-major", "version-update:semver-minor", "version-update:semver-patch"]
    # Under npm section:
    ignore:
      - dependency-name: "@cedar-policy/cedar-wasm"
        update-types: ["version-update:semver-major", "version-update:semver-minor", "version-update:semver-patch"]
  • Close PR chore(deps): uv: bump cedarpy from 4.8.0 to 4.8.2 in /agent in the all-python group across 1 directory #156 (Dependabot cedarpy bump — superseded by this coordinated change)

Acceptance criteria

  • Both bindings resolve to Cedar Rust 4.8.2
  • All parity fixtures pass on both sides
  • mise //cdk:test passes
  • agent/tests/test_cedar_parity.py passes
  • Dependabot will not propose independent cedar bumps going forward
  • Comment in pyproject.toml accurately reflects the parity relationship

Risk assessment

  • Downgrading cedar-wasm from 4.10.0 to 4.8.2 — this is a 2-minor-version downgrade. Cedar's policy language is backward-compatible; our policies don't use 4.9/4.10 features. The WASM API surface for isAuthorized is unchanged between these versions.
  • If parity fixtures fail after the change — this would indicate the current 4.10.0 engine was producing different results than 4.8.2 for our test vectors, meaning the gap was silently divergent. This would be a finding, not a failure — fix the root cause (policy incompatibility) rather than reverting.

Future: upgrading to Cedar 4.10+

When k9securityio publishes a cedarpy version wrapping Rust 4.10.x:

  1. Bump cedarpy to that version
  2. Bump cedar-wasm to 4.10.x (matching Rust core)
  3. Refresh parity fixtures
  4. Single coordinated commit

This is tracked as a monitoring responsibility in #104 (scheduled Action for coupling detection).

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions