Skip to content

docs(intent-presets): Rust from_env() no longer activates encryption (LAB-4669) - #200

Merged
27Bslash6 merged 5 commits into
mainfrom
lab-4669-rs-from-env-no-activation
Oct 25, 2026
Merged

27Bslash6 merged 5 commits into
mainfrom
lab-4669-rs-from-env-no-activation

Conversation

@27Bslash6

@27Bslash6 27Bslash6 commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

Flips the Rust cell of the intent-presets conformance row "CACHEKIT_MASTER_KEY does not activate encryption on minimal / production / io" from ❌ to ✅ cachekit-rs 0.12.0+, and brings every doc surface that named from_env() as an encryption switch or as the reader that applies CACHEKIT_PREVIOUS_MASTER_KEYS in line with cachekit-rs#173.

Why

Encryption Activation rule 2: CACHEKIT_MASTER_KEY is a key source, not an activation switch, and no constructor is exempt, an env-configuration constructor such as CacheKit::from_env() included. Through 0.11.x Rust's from_env() encrypted whenever the variable was set. From 0.12.0:

  • from_env() still reads and validates CACHEKIT_MASTER_KEY and CACHEKIT_PREVIOUS_MASTER_KEYS, but no longer encrypts because the key is set.
  • CacheKitBuilder::encryption_from_env() encrypts with the environment's keys, tenant "default". An unset or empty key is CachekitError::Config, never plaintext. Without the encryption feature it is Config, like the other builder encryption calls.
  • CacheKitBuilder::no_encryption() is the explicit opt-out (rule 3).
  • In 0.12.x, a from_env() builder that saw the key and states neither intent fails at build() with Config, feature on or off. That is a one-release gate of the same kind as cachekit 0.21.0's (migration step 3); the steady state builds plaintext.

What changed

  • spec/intent-presets.md: the rule 2 Rust cell (❌ → ✅ 0.12.0+); the rule 1 row's builder-method list gains .encryption_from_env() (0.12.0) and .encryption_with_previous() (0.11.0, missing since that release); design decisions (B) and (C); the verification paragraph records the 0.11.0 .crate check. No normative text changed.
  • sdk-feature-matrix.md: the Rust key-rotation cell, note ⁵, the Workers feature note (a feature-off from_env() with the key set is no longer a bare Config error), the backend-selection paragraph, the "CACHEKIT_MASTER_KEY auto-enables encryption" row and the preset-traps note.
  • spec/encryption.md (Key Rotation note) and decisions/key-rotation.md: secure_from_env and .encryption_from_env() apply the previous keys; from_env() did through 0.11.x.
  • conformance/coverage.md regenerated (two not-a-requirement line numbers shifted), and a changelog.d/ fragment added.

Code in cachekit-rs#173: CacheKit::from_env, CacheKitBuilder::encryption_from_env, CacheKitBuilder::no_encryption and the gate in CacheKitBuilder::build in crates/cachekit/src/client.rs, and master_keys_from_env in crates/cachekit/src/config.rs. The cells cite functions, not lines, because this document's Rust line refs are pinned to an older revision and the release's lines are not final.

Before marking ready

  • cachekit-rs 0.12.0 is on crates.io, and its .crate shows from_env() without activation, .encryption_from_env(), .no_encryption() and the 0.12.x build() gate as described.
  • Add the 0.12.0 .crate inspection date to the verification paragraph in spec/intent-presets.md § SDK Conformance and next to the 0.12.0 matrix claims, per decisions/matrix-version-verification.md.

Checks run

tools/conformance.py check --base origin/main and its mutation suite (284 cases), tools/check-version-floors.py with its suite, tools/check-spec-duplication.py, and tools/test_changelog_collect.py: all pass. 0.11.0 claims were checked against the published cachekit-rs-0.11.0.crate on 2026-10-23.

Published-crate verification (2026-10-26)

cachekit-rs-0.12.0.crate (sha256 3b4a5b09…2ba2) and cachekit-rs-0.13.0.crate (sha256 2e11a859…5539), both matching the crates.io index checksum. In both: CacheKit::from_env sets only env_master_key and never configures encryption; CacheKitBuilder::encryption_from_env reads both key variables through master_keys_from_env for tenant "default"; no_encryption and the build() check are byte-identical between the two releases. A probe binary depending on each published version, built with and without the encryption feature, observed:

CACHEKIT_MASTER_KEY Call encryption on encryption off
set from_env()?.build() Config Config
set from_env()?.no_encryption().build() Ok Ok
set from_env()?.encryption_from_env()?.build() Ok Config at encryption_from_env
set .encryption_from_env()?.no_encryption().build() Config (conflict) Config
unset from_env()?.build() Ok Ok
unset from_env()?.encryption_from_env() Config Config
empty builder().encryption_from_env() Config Config

The crates' own default-tenant vector tests pass: hex_path_ and env_path_decrypts_default_tenant_vector in both, and from_env_encryption_from_env_decrypts_default_tenant_vector in 0.13.0 only (absent from 0.12.0, as the default-tenant cell says). The inspection dates are now in the cells. tools/conformance.py check, its 284-case suite, check-version-floors.py, check-spec-duplication.py and test_changelog_collect.py pass at the new head.

cachekit-rs 0.12.0 brings CacheKit::from_env() in line with Encryption
Activation rule 2: it still reads and validates CACHEKIT_MASTER_KEY and
CACHEKIT_PREVIOUS_MASTER_KEYS, but a key in the environment no longer
makes the client encrypt. The new builder call .encryption_from_env()
encrypts with the environment's keys (tenant "default"), and the new
.no_encryption() is the explicit opt-out. In 0.12.x a from_env() builder
that saw the key and states neither fails at build(), a one-release gate
like cachekit 0.21.0's.

The Rust conformance cell for rule 2 flips to a 0.12.0 floor, the rule 1
row lists .encryption_from_env() and .encryption_with_previous() (0.11.0,
checked against the published crate), and design decisions (B) and (C)
no longer describe a from_env() carve-out. The feature matrix, the
keyring note in encryption.md and the key-rotation decision record stop
naming from_env() as a reader that applies the previous keys after
0.11.x. coverage.md is regenerated for the shifted line numbers.
@coderabbitai

coderabbitai Bot commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

Review in Change Stack →

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 34 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

Run configuration
Commits

Reviewing files that changed from the base of the PR and between 53ef052 and c163c97.

Files selected for processing: 4
  • changelog.d/20261023_lab-4669.md
  • sdk-feature-matrix.md
  • spec/encryption.md
  • spec/intent-presets.md

No actionable comments were generated in the recent review.

Recent review info
Run configuration
Commits

Reviewing files that changed from the base of the PR and between 6d80df5 and 53ef052.

Files selected for processing: 6
  • changelog.d/20261023_lab-4669.md
  • conformance/coverage.md
  • decisions/key-rotation.md
  • sdk-feature-matrix.md
  • spec/encryption.md
  • spec/intent-presets.md

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

Summary by CodeRabbit

  • Documentation
    • Clarified how Rust environment-based configuration handles encryption keys across versions, including the distinction between validating keys and explicitly enabling encryption.
    • Documented the transitional build-time check for keys supplied without encryption intent, and clarified opt-out and default-tenant behaviour.
    • Updated key-rotation guidance, SDK feature and conformance tables, and implementation records to reflect Rust 0.12.0 behaviour.
    • Corrected references to the relevant specification lines and refreshed artifact inspection details.

Walkthrough

The documentation records Rust encryption activation and key handling in cachekit-rs 0.12.0 and later. It distinguishes from_env() from .encryption_from_env() and updates conformance, feature-matrix, and key-rotation records. No normative text changed.

Changes

Rust encryption documentation

Layer / File(s) Summary
Encryption intent and conformance
spec/intent-presets.md, sdk-feature-matrix.md, changelog.d/20261023_lab-4669.md, conformance/coverage.md
The records distinguish from_env() from explicit encryption paths from 0.12.0, describe the transitional build-time intent check, and update verification history and coverage references.
Environment key-rotation paths
sdk-feature-matrix.md, spec/encryption.md, decisions/key-rotation.md
The documentation records that from_env() validates previous-key variables from 0.12.0, while .encryption_from_env() applies them. It also updates the Rust release history for these paths.

Priority: Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Other

Possibly related PRs

  • cachekit-io/protocol#206: Documents Rust default-tenant behaviour in spec/intent-presets.md, which this PR also updates.

Suggested reviewers: kodus-27b

Merge Risk: Minimal · up to 53ef0

No actionable merge-blocking risk remains.

Pre-merge checks: Passed 5
Check name Status Explanation
Title check Passed The title clearly identifies the main documentation change: Rust from_env() no longer activates encryption. It is concise and specific.
Description check Passed The description directly explains the documentation updates, the Rust 0.12.0 behaviour, verification evidence, and related files. It is relevant to the changeset.
Docstring Coverage Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check Passed Check skipped because no linked issues were found for this pull request.
Full details: Docstring Coverage

Explanation

No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (6 skipped: 6 unsupported.)

Finishing Touches
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

…nant cells, re-apply the from_env() changes

The transitional build() check is still in cachekit-rs 0.13.0, so the cells and changelog say "from 0.12.0" instead of "0.12.x". The default-tenant row gains .encryption_from_env(), which derives under "default" from 0.12.0.
…dates

The Rust from_env()/encryption_from_env()/no_encryption() claims and the
build() check were checked against the published cachekit-rs 0.12.0 and
0.13.0 .crates, per decisions/matrix-version-verification.md rule 5.
@27Bslash6
27Bslash6 marked this pull request as ready for review October 25, 2026 19:55
@kodus-27b

kodus-27b Bot commented Oct 25, 2026 •

Copy link
Copy Markdown

Code Review Completed! 🔥

The code review was successfully completed based on your current configurations.

Kody Guide: Usage and Configuration
Interacting with Kody
  • Request a Review: Ask Kody to review your PR manually by adding a comment with the `@kody start-review` command at the root of your PR.

  • Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Providing Context (Files & MCPs)

Add these hints in your PR description (or a comment) to unlock deeper checks:

  • Ticket / Acceptance Criteria: `Refs: ABC-123` (Linear/Jira/Asana/ClickUp/Trello) or a direct ticket link.
  • Bugfix Validation: a Sentry/Datadog/Bugsnag event link (or paste the stack trace/error message).
  • Endpoint Risk: mention the route (e.g., `POST /api/payments`) or controller/action name.
  • Attach a repo file as context: use an explicit marker like `@file:docs/guide.mdx#L10-L50` (replace with your real path).
  • API Contract Docs: include `@file:openapi.yaml` or `@file:swagger.json` when changing routes/schemas.
  • Definition of Done / Standards: include `@file:DOD.md` or `@file:CONTRIBUTING.md` if your repo has them.
  • Design System Source of Truth: include `@file:ui/index.ts` (replace with your DS entrypoint path).
  • Feature Flags: include the flag key/name and `@file:flags.ts` / `@file:config.json` (and optionally the PostHog flag name).
  • Edge/CDN Rules: link the Cloudflare rule/zone or describe the intended redirect/header behavior.
  • Attach an MCP tool output: use `@mcp<provider|tool>` (replace with an installed MCP provider + tool, e.g., `@mcp<sentry|events.search>`).
Current Kody Configuration
Review Options

The following review options are enabled or disabled:

Options Enabled
Bug ✅
Performance ✅
Security ✅
Business Logic ✅

Access your configuration settings here.

kodus-27b[bot]
kodus-27b Bot previously approved these changes Oct 25, 2026
coderabbitai[bot]
coderabbitai Bot previously approved these changes Oct 25, 2026
… bound the gate to 0.12.0-0.13.0

build() lets a from_env() builder through on any encryption call, not only
.encryption_from_env(). The gate's open 0.12.0 floors become 'still in 0.13.0'
so they stay true when it is retired. The changelog fragment now describes
what each matrix site says.
@kodus-27b

kodus-27b Bot commented Oct 25, 2026

Copy link
Copy Markdown

Code Review Completed! 🔥

The code review was successfully completed based on your current configurations.

Kody Guide: Usage and Configuration
Interacting with Kody
  • Request a Review: Ask Kody to review your PR manually by adding a comment with the `@kody start-review` command at the root of your PR.

  • Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Providing Context (Files & MCPs)

Add these hints in your PR description (or a comment) to unlock deeper checks:

  • Ticket / Acceptance Criteria: `Refs: ABC-123` (Linear/Jira/Asana/ClickUp/Trello) or a direct ticket link.
  • Bugfix Validation: a Sentry/Datadog/Bugsnag event link (or paste the stack trace/error message).
  • Endpoint Risk: mention the route (e.g., `POST /api/payments`) or controller/action name.
  • Attach a repo file as context: use an explicit marker like `@file:docs/guide.mdx#L10-L50` (replace with your real path).
  • API Contract Docs: include `@file:openapi.yaml` or `@file:swagger.json` when changing routes/schemas.
  • Definition of Done / Standards: include `@file:DOD.md` or `@file:CONTRIBUTING.md` if your repo has them.
  • Design System Source of Truth: include `@file:ui/index.ts` (replace with your DS entrypoint path).
  • Feature Flags: include the flag key/name and `@file:flags.ts` / `@file:config.json` (and optionally the PostHog flag name).
  • Edge/CDN Rules: link the Cloudflare rule/zone or describe the intended redirect/header behavior.
  • Attach an MCP tool output: use `@mcp<provider|tool>` (replace with an installed MCP provider + tool, e.g., `@mcp<sentry|events.search>`).
Current Kody Configuration
Review Options

The following review options are enabled or disabled:

Options Enabled
Bug ✅
Performance ✅
Security ✅
Business Logic ✅

Access your configuration settings here.

kodus-27b[bot]
kodus-27b Bot previously approved these changes Oct 25, 2026
secure_from_env also applies the env previous keys, so note 5 ends at "only
validates it". "The only constructor the key activated" and "(0.12.0+)" in
the changelog fragment fix two misleading antecedents.
@kodus-27b

kodus-27b Bot commented Oct 25, 2026

Copy link
Copy Markdown

Code Review Completed! 🔥

The code review was successfully completed based on your current configurations.

Kody Guide: Usage and Configuration
Interacting with Kody
  • Request a Review: Ask Kody to review your PR manually by adding a comment with the `@kody start-review` command at the root of your PR.

  • Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Providing Context (Files & MCPs)

Add these hints in your PR description (or a comment) to unlock deeper checks:

  • Ticket / Acceptance Criteria: `Refs: ABC-123` (Linear/Jira/Asana/ClickUp/Trello) or a direct ticket link.
  • Bugfix Validation: a Sentry/Datadog/Bugsnag event link (or paste the stack trace/error message).
  • Endpoint Risk: mention the route (e.g., `POST /api/payments`) or controller/action name.
  • Attach a repo file as context: use an explicit marker like `@file:docs/guide.mdx#L10-L50` (replace with your real path).
  • API Contract Docs: include `@file:openapi.yaml` or `@file:swagger.json` when changing routes/schemas.
  • Definition of Done / Standards: include `@file:DOD.md` or `@file:CONTRIBUTING.md` if your repo has them.
  • Design System Source of Truth: include `@file:ui/index.ts` (replace with your DS entrypoint path).
  • Feature Flags: include the flag key/name and `@file:flags.ts` / `@file:config.json` (and optionally the PostHog flag name).
  • Edge/CDN Rules: link the Cloudflare rule/zone or describe the intended redirect/header behavior.
  • Attach an MCP tool output: use `@mcp<provider|tool>` (replace with an installed MCP provider + tool, e.g., `@mcp<sentry|events.search>`).
Current Kody Configuration
Review Options

The following review options are enabled or disabled:

Options Enabled
Bug ✅
Performance ✅
Security ✅
Business Logic ✅

Access your configuration settings here.

@27Bslash6
27Bslash6 merged commit 19fb390 into main Oct 25, 2026
5 checks passed
@27Bslash6
27Bslash6 deleted the lab-4669-rs-from-env-no-activation branch October 25, 2026 20:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant