-
Notifications
You must be signed in to change notification settings - Fork 414
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
Default reverse resolver #335
Default reverse resolver #335
Conversation
makoto
commented
Feb 26, 2024
•
edited
Loading
edited
- Add DefaultResolver
- Add SignatureResolver which is the super class of DefaultResolver and L2ReverseRegistrar
- Change signature to use eip 191 version 0
Co-authored-by: Nick Johnson <[email protected]>
…ins/ens-contracts into default-reverse-resolver
* @param addr The node to update. | ||
* @param signature A signature proving ownership of the node. | ||
*/ | ||
function clearRecordsWithSignature( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this works with signed messages; someone replaying a series of messages could choose to include or omit the clear
signed message, producing different results either way.
Perhaps instead we can include a version in each signature message, and if the version is greater than the one stored, increment it, effectively erasing all past records?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am failing to understand why this is only issue for clearRecords
but not for other set*
functions. Also the inclusion of the version doesn't help when the someone keeps omitting to include the clear
signed message.
Isn't inceptionDate
enough against most abuses?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right; to be properly secure, inception dates would need to be recorded on each individual record (in the case of parameterised values such as text, on each key of each record); otherwise someone can replay just the last event, making it impossible to set earlier ones.
If someone omits a message, someone else can supply it - the issue is cases where omitting an earlier message but including a later one makes it impossible to supply the missing message later and arrive at the same end result.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
otherwise someone can replay just the last event, making it impossible to set earlier ones.
That would be problematic if we have a counter logic (eg: n=n+1
) where the state depends on previous state. However, all setter*
message simply overrides the previous state so there isn't much point supplying the missing message later.
I also didn't fully understand for inception dates would need to be recorded on each individual record
Are you suggesting to change from
function _setLastUpdated(bytes32 node, uint256 inceptionDate) internal {
lastUpdated[node] = inceptionDate;
}
to
function _setTextLastUpdated(bytes32 node, string key, uint256 inceptionDate) internal {
lastUpdated[node][key] = inceptionDate;
}
then change isAuthorisedWithSignature
to take key
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be problematic if we have a counter logic (eg: n=n+1) where the state depends on previous state. However, all setter* message simply overrides the previous state so there isn't much point supplying the missing message later.
They don't, though - setting the address for one coin type invalidates all other previous messages to set addresses for other coin types. The same goes for text records.
Either the last updated value needs to be per-key as you illustrate, or we need to change this to function differently - for example, by taking a complete set of records to set in a single operation, and increment the version at the same time. If going with the former, probably the last updated check should be moved outside isAuthorisedWithSignature
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
* @param addr The node to update. | ||
* @param signature A signature proving ownership of the node. | ||
*/ | ||
function clearRecordsWithSignature( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right; to be properly secure, inception dates would need to be recorded on each individual record (in the case of parameterised values such as text, on each key of each record); otherwise someone can replay just the last event, making it impossible to set earlier ones.
If someone omits a message, someone else can supply it - the issue is cases where omitting an earlier message but including a later one makes it impossible to supply the missing message later and arrive at the same end result.
Line 73 of what file? I can't see anywhere that would require this to be a separate parameter to the outer signature. |
Co-authored-by: Nick Johnson <[email protected]>
…ins/ens-contracts into default-reverse-resolver
1736e33
into
feature/crosschain-resolver-with-reverse-registrar