-
Notifications
You must be signed in to change notification settings - Fork 87
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
Add missing ClientType
, ClientId
validation checks
#639
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #639 +/- ##
==========================================
+ Coverage 73.07% 73.09% +0.02%
==========================================
Files 126 126
Lines 15678 15665 -13
==========================================
- Hits 11456 11450 -6
+ Misses 4222 4215 -7
☔ View full report in Codecov by Sentry. |
ClientType
validation methodClientType
validations
ClientType
validationsClientType
, ClientId
validation checks
In #642 we removed |
Yes. Actually, we still have to keep the |
let last_index = split_id.len() - 1; | ||
let prefix = split_id[..last_index].join("-"); | ||
|
||
validate_prefix_identifier(prefix.trim(), min, max)?; |
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.
The whole identifier must be between min/max length; not just the prefix
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.
Ah, the validate_prefix_identifier
does the length checks with the "full id" using 0 and u64::MAX
. Although correct, that's a little confusing.
A more general question: what was wrong with the previous identifier validation?
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.
It is so.
validate_prefix_identifier
performs this check just after creating "min/max default identifiers" and passing them to the validate_default_identifier
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.
Before, here we were allowing wrong ClientId
creation. E.g. "mock_clientid", "nonexistingclient" were ok.
Also, "07-tendermint-" and " 07-tendermint " as a valid ClientType
s were accepted.
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.
They are okay though; according to the spec, those are all valid identifiers, and this is the only requirement for client identifiers. Our ChainId
type also properly handles identifiers that are not in the "epoch" format
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 believe ibc-go has these extra restrictions, but only for their ClientType
. Other chains are free to name their clients without these extra restrictions
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.
They are okay though; according to the spec, those are all valid identifiers, and this is the only requirement for client identifiers. Our ChainId type also properly handles identifiers that are not in the "epoch" format
Our client creator restricts. #639 (comment)
Thus, Should we move away from the client counter?
#[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))] | ||
/// Type of the client, depending on the specific consensus algorithm. | ||
#[derive(Clone, Debug, PartialEq, Eq, PartialOrd, Ord, Hash)] | ||
pub struct ClientType(String); |
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.
why does it make more sense for ClientType to be in ics24_host? It’s still used as a prefix to a ClientId; seems to make more sense to live under ics02_client?
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.
Since all the identifiers including the ClientId
live in ICS24_host
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.
ICS-24 defines the concept of an identifier. ClientType
is, well, the "type" of a client, which turns out is used to create an identifier; it is not an identifier itself. Basically, it is a "client" concept, which is also used to create identifiers. I think it makes more sense for it to live where it was
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.
Maybe naming is getting us confused. We don't have such a type in the spec anymore, and honestly, Looking into the role of/functionality ClientType
already serves (being only used as part/prefix of ClientId
). It's more of ClientIdPrefix
, so I still think it should be placed in ics24. Though, it's not a big deal. Alright
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.
/// A valid identifier must be between 9-64 characters and only contain lowercase | ||
/// alphabetic characters, | ||
/// A valid client identifier must be between 9-64 characters as specified in | ||
/// the ICS-24 spec. | ||
pub fn validate_client_identifier(id: &str) -> Result<(), Error> { | ||
validate_identifier(id, 9, 64) |
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.
This is no longer correct; client identifiers are not required to be in the {client_type}-version
format
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.
Indeed. Not required by spec. Though, check here please. This is the only format we allow for client creation.
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.
Another point:
This validate_prefix_identifier
will also be used to check the validity of ConnectionId
and ChannelId
creation from String
to be of {identifier}-u64
format. You can see its usage in #650
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.
It is the current way that we create client identifiers, which is a subset of all allowed client identifiers. In other words, if ever we changed how we do this in the future (e.g. to allow for other formats), then this validate_client_identifier()
would fail for valid identifiers. This method should check the validity of client identifiers according to the spec, which will make sure that no matter how we create our client identifiers, they will be valid
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.
As per our discussion, needed changes applied. Please check it out again.
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.
👌
* Add missing ClientType validation * Move ClientType verification under validate.rs to cover all needed checks * Move ClientType tests into the validate.rs * Some adjustments * Fix tests * Mend ClientId for upgrade-client tests * Rename to default_validate_identifier * Refactor for more generic functions * Revise changelog * Add missing counterparty client_id check * Remove duplicate checks and unnecessary methods * Add missing changelog * From<String> instead of new_unchecked * Revert ClientType placement * Removed unnecessary checks and improved naming * Fix some nits
Closes: #621
Description
Considering that the
create_client
handler always adds a counter to theClientId
. This PR uncovered some of our tests were using a wrongClientId
The
ClientType
serves being a part of theClientId
(prefix) and the purpose is to construct client identifiers. So, it has been relocated under the ICS24 section. This move will make more sense if you review the changes in the PR, including the associated errors and how it interacts withClientId
. Also, should be noted we already don’t have anyClientType
in the spec.Since
ClientId
andClientType
are tightly related types, this PR covers missing checks forClientId
too, ensuring we cover all validation checks needed.IBC-go has more restrictions on the format of
ClientId
, which seems to be required by SDKs. My goal was to impose less checks allowing for a wider range of identifiersNote: Similarly,
ConnectionId
andChannelId
checks will be taken care after the completion of this PRPR author checklist:
unclog
.docs/
).Reviewer checklist:
Files changed
in the GitHub PR explorer.