Repository navigation
docs(intent-presets): Rust from_env() no longer activates encryption (LAB-4669) - #200
Conversation
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.
|
Warning Review limit reachedYou'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. View limit details
No actionable comments were generated in the recent review.
|
| 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:
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: 
5
-
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.
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.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
… 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.
3f0af13
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
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.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
Flips the Rust cell of the intent-presets conformance row "
CACHEKIT_MASTER_KEYdoes not activate encryption onminimal/production/io" from ❌ to ✅cachekit-rs0.12.0+, and brings every doc surface that namedfrom_env()as an encryption switch or as the reader that appliesCACHEKIT_PREVIOUS_MASTER_KEYSin line with cachekit-rs#173.Why
Encryption Activation rule 2:
CACHEKIT_MASTER_KEYis a key source, not an activation switch, and no constructor is exempt, an env-configuration constructor such asCacheKit::from_env()included. Through 0.11.x Rust'sfrom_env()encrypted whenever the variable was set. From 0.12.0:from_env()still reads and validatesCACHEKIT_MASTER_KEYandCACHEKIT_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 isCachekitError::Config, never plaintext. Without theencryptionfeature it isConfig, like the other builder encryption calls.CacheKitBuilder::no_encryption()is the explicit opt-out (rule 3).from_env()builder that saw the key and states neither intent fails atbuild()withConfig, feature on or off. That is a one-release gate of the same kind ascachekit0.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.cratecheck. No normative text changed.sdk-feature-matrix.md: the Rust key-rotation cell, note ⁵, the Workers feature note (a feature-offfrom_env()with the key set is no longer a bareConfigerror), the backend-selection paragraph, the "CACHEKIT_MASTER_KEYauto-enables encryption" row and the preset-traps note.spec/encryption.md(Key Rotation note) anddecisions/key-rotation.md:secure_from_envand.encryption_from_env()apply the previous keys;from_env()did through 0.11.x.conformance/coverage.mdregenerated (two not-a-requirement line numbers shifted), and achangelog.d/fragment added.Code in cachekit-rs#173:
CacheKit::from_env,CacheKitBuilder::encryption_from_env,CacheKitBuilder::no_encryptionand the gate inCacheKitBuilder::buildincrates/cachekit/src/client.rs, andmaster_keys_from_envincrates/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
.crateshowsfrom_env()without activation,.encryption_from_env(),.no_encryption()and the 0.12.xbuild()gate as described..crateinspection date to the verification paragraph inspec/intent-presets.md§ SDK Conformance and next to the 0.12.0 matrix claims, perdecisions/matrix-version-verification.md.Checks run
tools/conformance.py check --base origin/mainand its mutation suite (284 cases),tools/check-version-floors.pywith its suite,tools/check-spec-duplication.py, andtools/test_changelog_collect.py: all pass. 0.11.0 claims were checked against the publishedcachekit-rs-0.11.0.crateon 2026-10-23.Published-crate verification (2026-10-26)
cachekit-rs-0.12.0.crate(sha2563b4a5b09…2ba2) andcachekit-rs-0.13.0.crate(sha2562e11a859…5539), both matching the crates.io index checksum. In both:CacheKit::from_envsets onlyenv_master_keyand never configures encryption;CacheKitBuilder::encryption_from_envreads both key variables throughmaster_keys_from_envfor tenant"default";no_encryptionand thebuild()check are byte-identical between the two releases. A probe binary depending on each published version, built with and without theencryptionfeature, observed:CACHEKIT_MASTER_KEYencryptiononencryptionofffrom_env()?.build()ConfigConfigfrom_env()?.no_encryption().build()from_env()?.encryption_from_env()?.build()Configatencryption_from_env.encryption_from_env()?.no_encryption().build()Config(conflict)Configfrom_env()?.build()from_env()?.encryption_from_env()ConfigConfigbuilder().encryption_from_env()ConfigConfigThe crates' own default-tenant vector tests pass:
hex_path_andenv_path_decrypts_default_tenant_vectorin both, andfrom_env_encryption_from_env_decrypts_default_tenant_vectorin 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.pyandtest_changelog_collect.pypass at the new head.