Skip to content

BM-871: Always revert on invalid context #605

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

capossele
Copy link
Contributor

Addressing @nategraf comments mentioned in #596 :

  1. Adjust the comment at the top of this function to reflect the existence of this kind of weird edge case around a request becoming fulfilled without payment being sent.
  2. Document (and double check) the invariant that the first ProofDelivered event should coincide with a Fulfilled event in all cases.
  3. Revert on !context.valid. This is actually a separate bug I am just noticing now. The issue is that, in particular for smart contract signed requests, the signature check on a request happens in the priceReqeust function. The current implementation using return instead of revert creates an issue where a third party can cancel someone else request by crafting a request with the same ID and fulfilling it before any lock occurs. They can do so without the request ever being signed.

@github-actions github-actions bot changed the title Always revert on invalid context BM-871: Always revert on invalid context May 6, 2025
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

L591 in this file is an inaccurate comment at this point.

@nategraf
Copy link
Member

nategraf commented May 6, 2025

I pushed fcd7ba3 with a couple of code comments, and verified that the invariant I describe currently holds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants