You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Context and scope
Currently, an empty allowed-origin-sender-addresses or supported-destinations is used to indicate that there are no restrictions on allowed senders or destinations. Under the hood, this writes to a concrete DB key that can cause surprising behavior in some scenarios.
Discussion and alternatives
To mitigate against any surprises, we should change the semantics of the allowed lists such that an empty list corresponds to no allowed senders/destinations. In order to allow any sender/destination, an entry must be explicitly provided in those lists.
Open questions
What key should we use for the "allow any" case? Currently, this case translates to the zero address/empty blockchain ID, but there are scenarios in which these zero values are explicitly set in Warp messages.
How should we validate the config? If the "allow any" key is provided, should we disallow any other concrete entries?
The text was updated successfully, but these errors were encountered:
Context and scope
Currently, an empty
allowed-origin-sender-addresses
orsupported-destinations
is used to indicate that there are no restrictions on allowed senders or destinations. Under the hood, this writes to a concrete DB key that can cause surprising behavior in some scenarios.Discussion and alternatives
To mitigate against any surprises, we should change the semantics of the allowed lists such that an empty list corresponds to no allowed senders/destinations. In order to allow any sender/destination, an entry must be explicitly provided in those lists.
Open questions
The text was updated successfully, but these errors were encountered: