fix: prevent access to secrets not in scope - #24616
Merged
Merged
Conversation
mverzilli
approved these changes
Jul 9, 2026
getSharedSecrets threw (via getCompleteAddressOrFail) when the PXE holds no keys for an in-scope address, e.g. syncing a registered but non-owned account. That aborted the entire sync for non-deployed recipients. Restore returning an empty array in that case, so handshake secret gathering skips messages it cannot decrypt and continues. The scope authorization check added earlier is preserved and still runs first.
PhilWindle
pushed a commit
that referenced
this pull request
Jul 21, 2026
Some stores were being accessed without checking if the associated accounts were in scope or not. For logs I added this to the service, but we're not yet consistent in how we use services (call-lived, tx-lived?) so in other cases it is just inlined in the oracle. (cherry picked from commit ce12e29)
PhilWindle
pushed a commit
that referenced
this pull request
Jul 21, 2026
Some stores were being accessed without checking if the associated accounts were in scope or not. For logs I added this to the service, but we're not yet consistent in how we use services (call-lived, tx-lived?) so in other cases it is just inlined in the oracle. (cherry picked from commit ce12e29)
rangozd
pushed a commit
to rangozd/aztec-packages
that referenced
this pull request
Aug 5, 2026
Some stores were being accessed without checking if the associated accounts were in scope or not. For logs I added this to the service, but we're not yet consistent in how we use services (call-lived, tx-lived?) so in other cases it is just inlined in the oracle. (cherry picked from commit ce12e29)
rangozd
pushed a commit
to rangozd/aztec-packages
that referenced
this pull request
Aug 5, 2026
…ecProtocol#24932) Forward-ports the **pxe / client / txe** slice of the v5-next → next backlog (work merged to `v5-next` after the ~2026-07-08 cut that reshaped `next`). ## Applied (clean cherry-picks, chronological) - fix: tweak depositToAztec gas config (AztecProtocol#24607) - refactor: cache Aztec node reads per execution (AztecProtocol#24630) - fix: prevent access to secrets not in scope (AztecProtocol#24616) - docs: fee readme improvements (AztecProtocol#24666) - fix(pxe): widen tracked sender tagging ranges with onchain discovery evidence (AztecProtocol#24655) - fix: tagging secrets not being scoped by sender (AztecProtocol#24772) ## Conflict resolutions (cherry-picked with `-x`, resolved against reshaped `next`) - fix(txe): align tagging strategy oracle with PXE (AztecProtocol#24561) — TXE oracle version bumped to 4.0 (breaking rename `setTaggingSecretStrategy` -> `setTaggingSecretStrategies`; `next` was at 3.0 with its own hash), interface hash recomputed on the merged registry. Migration note dropped: already on `next` under 5.0.0. - feat(pxe)!: Add AppTaggingSecret kinds to keys in tagging stores (AztecProtocol#24604) — `PXE_DATA_SCHEMA_VERSION` 12 -> 13 applies cleanly on `next`. Migration note dropped: already on `next` under 5.0.0. - feat: add batch is block in archive oracle (AztecProtocol#24634) — applied cleanly on top of AztecProtocol#24561; contract oracle version 30.6 -> 30.7, v5 interface hash matched the merged registry. - feat: getTxEffects oracle (AztecProtocol#24636) — applied cleanly. - ~~feat: preserve stores on schema version or rollup address change (AztecProtocol#24631)~~ — ported separately via AztecProtocol#24947 together with the rest of the sqlite/OPFS line - feat(txe): add option to authorize all utility call targets (AztecProtocol#24662) — additive on our 4.0 -> TXE oracle version 4.1 (was 3.0 -> 3.1 on v5), hash recomputed. - refactor(pxe): compute oracle interface hash from wire-structural mapping labels (AztecProtocol#24752) — TXE hash recomputed under the new wire-structural scheme; PXE hash from the pick matched. Verified locally: full `yarn build`, `check_oracle_version` + `check_txe_oracle_version`, TXE unit suite (21), pxe tagging/type-mapping/utility-oracle suites, and 29 targeted aztec-nr + onchain_delivery_test_contract TXE tests — all green. Part of the manual v5-next → next backlog sweep. ## Added after review - AztecProtocol#24627 fix(aztec.js): give waitForNode a bounded default timeout — missed by the initial sweep (merge-commit wrapper + non-`(#N)` leaf); genuinely absent from `next`.
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
2 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.
Some stores were being accessed without checking if the associated accounts were in scope or not. For logs I added this to the service, but we're not yet consistent in how we use services (call-lived, tx-lived?) so in other cases it is just inlined in the oracle.