Repository navigation
encryption: serve named-key routes and resources only when named keys are enabled - #430
Merged
Merged
Conversation
added 3 commits
October 23, 2026 19:40
… are enabled Details: TC-1777
samgbafa
marked this pull request as ready for review
October 23, 2026 19:53
Contributor
Author
|
APPROVE: see TC-1777 (reviewed exact head 9248aa0) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
[global.encryption_network] named_keys_v1(envTINYCLOUD_ENCRYPTION_NETWORK__NAMED_KEYS_V1, default off) now controls whether the node serves named keys. With it off:POST /encryption/networks/<network_id>/keys, the twoGET …/keys/<key_path..>ranks,POST …/key-actions/blockand…/unblock) are not mounted, so those paths answer 404 as any unmounted path does. The network routes (/encryption/networks,…/<network_id>,…/decrypt,…/revoke, the well-known record) are mounted either way.validate_withintinycloud-core/src/models/delegation.rsrefuses any delegation with a capability on a key or key prefix (Resource::is_named_key, usingkey_id::parse). It runs over all capabilities before the root-authority filter, so a delegation the key's owner signs is covered, for UCAN and CACAO alike.POST /delegateanswers 401named_keys_unavailable: named keys are not enabled on this node. The setting reaches core throughSpaceDatabase::with_named_keys, threaded totransactandprocess_withthe waydelegated_sql_caveatsis.POST /invokeanswers 403 with the same text for an invocation with a capability on a key or key prefix. Decrypt on a bare network is unchanged.With it on, behavior is unchanged. The test fixture (
KvSyncFixture::new_with) now setsnamed_keys_v1 = true, so the existing key tests run as before.Tests:
tinycloud-core:named_key_grants_are_refused_when_named_keys_are_off(owner and non-owner, key and prefix, bare network unaffected, on admits).routes::tests::encryption_keys:delegate_refuses_named_key_resources_when_named_keys_are_off(UCAN, owner-signed, key/prefix/mixed, nothing stored, bare network admitted),delegate_admits_named_key_resources_when_named_keys_are_on,invoke_refuses_named_key_resources_when_named_keys_are_off(key, prefix; bare network decrypt still 200).policy_v3::named_keys_gate_tests(booted throughapp_with_control, SQLite and PostgreSQL variants): the five key routes answer the same as an unmounted path while the network routes still answer; owner-signed key and prefix delegations refused for did:key (UCAN) and did:pkh (SIWE CACAO) owners.production_route_tests::named_key_routes_are_mounted_only_when_named_keys_are_on./infolisting without the feature is covered by the existingnamed_keys_feature_is_advertised_only_behind_its_gate.Details: TC-1777