ceramicnetwork / rust-ceramic

Implementation of the Ceramic protocol in Rust
Other
37 stars 10 forks source link

feat: validate signed events #503

Closed dav1do closed 1 month ago

dav1do commented 2 months ago

Initial implementation of validation for signed events. The Validation module accepts the list of events, partitions them into "time" and "signed" events and delegates the validation to the appropriate handler.

The signed validator will validate events against the init controller and if it's unable to find the init event, will consider them unvalidated. The service decides whether this is an error or acceptable based on the ValidationRequirement allow_pending value. If pending is supported, they are tracked in memory until the required init event is found, otherwise they are considered an error.

When verifying against the init event we check the CACAO resources, the CACAO and envelope signatures and the delegation chain, but we currently assume all streams are MIDs when constructing the stream ID to use.

This targets #505 #526 and is not enabled by default yet as it is behind an experimental feature flag: --experimental-feature-flags event-validation.

linear[bot] commented 2 months ago

AES-277 validate writes from api/recon before storing

dav1do commented 1 month ago

sorry for so many comments, this PR is really massive. I feel like maybe if we pulled out the implementation of the validator crate into its own PR it would be a bit more manageable?

I'll see what I can do in the morning.. the bulk of this PR is just the validator module but there is some behavior around pending and other changes that might be a distraction. The validator crate to do signature verification already exists, this module is mostly to group/find/orchestrate everything needed to be able to verify a envelope and cacao against the init controller and figure out if it's a hard error or a "maybe error".

dav1do commented 1 month ago

sorry for so many comments, this PR is really massive. I feel like maybe if we pulled out the implementation of the validator crate into its own PR it would be a bit more manageable?

I'll see what I can do in the morning.. the bulk of this PR is just the validator module but there is some behavior around pending and other changes that might be a distraction. The validator crate to do signature verification already exists, this module is mostly to group/find/orchestrate everything needed to be able to verify a envelope and cacao against the init controller and figure out if it's a hard error or a "maybe error".

Split some changes out in #526. Most of the feedback about clarifying comments/names were addressed in that PR. This PR actually does the signature validation. If it's easier to close and reopen a new one, I can do that. I still have the original branch/commits locally but after rebasing onto main and splitting things out, the original breakdown of changes wasn't super helpful so I squashed them and split them up differently.