Skip to content

feat: merge-train/fairies - #25030

Merged
nchamo merged 2 commits into
nextfrom
merge-train/fairies
Jul 28, 2026
Merged

feat: merge-train/fairies#25030
nchamo merged 2 commits into
nextfrom
merge-train/fairies

Conversation

@AztecBot

@AztecBot AztecBot commented Jul 28, 2026

Copy link
Copy Markdown
Collaborator

BEGIN_COMMIT_OVERRIDE
refactor: split noir-projects into fnd/ and labs/ (#25007)
fix(aztec-nr): restrict raw note-enqueue sink to pub(crate) (#24974)
END_COMMIT_OVERRIDE

@nchamo
nchamo enabled auto-merge July 28, 2026 14:50
@nchamo
nchamo added this pull request to the merge queue Jul 28, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jul 28, 2026
Fixes [F-832
](https://linear.app/aztec-labs/issue/F-832/aztec-packages-aztec-nr-custom-message-handler-can-enqueue-an)

Reduce `enqueue_note_for_validation` and `NoteValidationRequest` from
`pub` to `pub(crate)`. These are only ever called by aztec-nr's own
discovery paths, which run nonce discovery before enqueuing so every
enqueued note's unique hash is guaranteed present in the tx effects.

Addresses F-832 as API hygiene rather than a security boundary. Two
distinct threat models:

1. F-832's actual threat: malicious sender vs honest contract. The
honest author uses documented, pub APIs in good faith. A pub raw sink
that looks like "the way to deliver a note from a handler" invites them
to wire it up, and then any sender could brick others. Removing it from
the pub surface means an honest author can't build the vulnerable
pattern.
2. Malicious/broken contract author. Unpreventable: they can recompute
the slot, push directly, or just panic in a handler. aztec-nr can't and
does not need to stop this. The only people harmed are users who chose
to run that bad contract, and the blast radius is that one contract's
scope.

Maybe we do not even deem this `pub(crate)` restriction worth it as I do
not think custom message handlers have high demand at this point. But it
felt easy enough to restrict the API here. If they ever do have large
demand perhaps we should think through our APIs a bit further as to help
custom message handlers avoid foot-guns. Once custom handlers become
more heavily used we could consider APIs that at least push devs towards
inclusion being checked or provide boilerplate for safe custom handlers
@nchamo nchamo self-assigned this Jul 28, 2026
@nchamo
nchamo added this pull request to the merge queue Jul 28, 2026
Merged via the queue into next with commit 6ede6cf Jul 28, 2026
24 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants