confidentialrelay: forward vault public key through GetRawSecrets, bind into hash - #2429
Merged
Merged
Conversation
Contributor
|
👋 prashantkumar1982, thanks for creating this pull request! To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team. Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks! |
Contributor
|
jmank88
requested changes
Sep 30, 2026
jmank88
left a comment
jmank88
left a comment
Contributor
There was a problem hiding this comment.
Can we find a way to do this without making a breaking API change?
Contributor
Author
Ahh thanks @jmank88, sorry i missed the breaking change part. Yes, we shouldn't make a breaking API change. Fixing it now. |
…common into relay-secrets-response-public-key
prashantkumar1982
force-pushed
the
relay-secrets-response-public-key
branch
from
September 30, 2026 15:54
22e1de1 to
77faf1d
Compare
jmank88
approved these changes
Sep 30, 2026
prashantkumar1982
enabled auto-merge
September 30, 2026 16:41
cfal
approved these changes
Sep 30, 2026
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
3 participants
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.
Motivation
Follow-up to the Vault reshare zero-downtime PublicKey work. The Vault
GetSecretsresponse carriesraw_vault_public_key(the key of the DKG instance that produced the shares) so decrypt-side callers verify/aggregate against the live key. That already reaches the enclave on the initial compute request, but runtime secret reads in confidential workflows go through the confidential-relay path, which dropped the key:GetRawSecretsreturned only[]*vault.SecretResponse, andSecretsResponseResulthad no public-key field. After a reshare, runtimegetSecretreceives shares from the new DKG but the enclave verifies them with its stale configured key, so aggregation fails.Change
ExecutionHelperWithRawSecrets.GetRawSecretsnow returns the full*vault.GetSecretsResponse, so the top-levelRawVaultPublicKeysurvives to the relay handler. The restriction wrapper repackages the filtered responses plus the key.SecretsResponseResultgainsRawVaultPublicKeyand it is bound intoHash(), so the enclave can trust the forwarded key as authorization-covered.ExecutionHelperWithRawSecretsmock and updated affected tests.Downstream
Prerequisite for:
RawVaultPublicKey;secretsFetcher/RawSecretsFetcherreturn the full response.remoteDispatcherprefersresult.RawVaultPublicKeyover its configuredMasterPublicKey, with fallback.Because the key is bound into the signed hash, the relay signer (chainlink) and the enclave verifier (conf-compute) must ship together.