Problem: sender check for MsgStoreBlockList is not in CheckTx #1613
Conversation
mmsqe
requested review from
JayT106 and
thomas-nguy
and removed request for
a team
WalkthroughThe changes introduced in this pull request include updates to the Changes
Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1613 +/- ##
==========================================
+ Coverage 36.00% 36.31% +0.31%
==========================================
Files 123 123
Lines 9791 9715 -76
==========================================
+ Hits 3525 3528 +3
+ Misses 5851 5773 -78
+ Partials 415 414 -1
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (5)
x/cronos/types/messages_test.go (1)
66-69: Suggestion: Improve error handling in key parsing.The current implementation uses
log.Fatalfwhich will terminate the program if the key parsing fails. In a test context, it might be more appropriate to uset.Fatalfto fail the test instead.Consider replacing the error handling with:
- if err != nil { - log.Fatalf("Failed to parse public key %q: %v", publicKey, err) - } + require.NoError(t, err, fmt.Sprintf("Failed to parse public key %q", publicKey))This change will provide more consistent error reporting within the test framework.
x/cronos/types/messages.go (3)
338-339: LGTM. Consider adding a comment explaining the chosen value.The introduction of
MaximumBlobLengthis a good practice to limit the size of theBlobfield. However, it would be beneficial to add a comment explaining why 20480 (20 KB) was chosen as the maximum length. This helps future maintainers understand the reasoning behind this limit.Consider adding a comment like:
// MaximumBlobLength defines the maximum allowed length for the Blob field. // It is set to 20 KB to [explain the reason for this specific limit]. const MaximumBlobLength = 20480
347-350: LGTM. Consider a minor optimization.The new validation logic for the blob length is correct and well-implemented. It properly enforces the
MaximumBlobLengthlimit and provides a clear error message.For a minor optimization, consider storing the length in a variable to avoid calling
len(msg.Blob)twice:blobLength := len(msg.Blob) if blobLength > MaximumBlobLength { return errors.Wrapf(sdkerrors.ErrInvalidRequest, "block length %d must not exceed %d", blobLength, MaximumBlobLength) }This change would slightly improve readability and prevent redundant length calculations.
355-356: LGTM. Consider clarifying the comment slightly.The added comment provides valuable context for the use of
errDummyIdentityin theDecryptoperation. It's helpful in explaining the rationale behind this error handling approach.To improve clarity, consider slightly rewording the comment:
// Use errDummyIdentity for early return to skip heavy decryption operation. // This approach is based on the implementation in: // https://github.com/FiloSottile/age/blob/v1.1.1/age.go#L197This rewording makes the purpose of using
errDummyIdentitymore explicit and separates the explanation from the reference link.CHANGELOG.md (1)
Line range hint
13-29: Consider adding release date for v1.0.7For better version tracking and historical reference, it would be helpful to include the release date for v1.0.7 in the changelog.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- CHANGELOG.md (1 hunks)
- x/cronos/types/messages.go (1 hunks)
- x/cronos/types/messages_test.go (2 hunks)
🧰 Additional context used
🪛 Gitleaks
x/cronos/types/messages_test.go
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (5)
x/cronos/types/messages_test.go (2)
17-17: LGTM: Bech32 prefix configuration added.The addition of
cmdcfg.SetBech32Prefixes(sdk.GetConfig())ensures consistent address formatting across tests, which is a good practice for maintaining test reliability.
62-135: LGTM: Comprehensive test cases for MsgStoreBlockList validation.The new test function
TestValidateMsgStoreBlockListeffectively addresses the PR objective of validating maximum length for blob messages. The test cases cover various scenarios, including valid input, exceeding maximum blob length, invalid sender address, and decryption errors. The use of age encryption adds a layer of security to the blob storage mechanism.🧰 Tools
🪛 Gitleaks
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
x/cronos/types/messages.go (1)
338-356: Overall, the changes look good and address the PR objectives.The modifications to
x/cronos/types/messages.gosuccessfully implement max length validation for blob messages in theMsgStoreBlockListstruct. The changes are well-implemented, consistent with the existing code style, and improve the robustness of the system.Key improvements:
- Introduction of
MaximumBlobLengthconstant.- Implementation of blob length validation in
ValidateBasic.- Addition of a helpful comment explaining the
errDummyIdentityusage.The suggestions provided in the review are minor and aimed at further improving code clarity and efficiency. Overall, these changes effectively address the issue of "no max length validation for blob msg" as described in the PR objectives.
CHANGELOG.md (2)
11-11: LGTM: New feature added to changelogThe addition of max length validation for blob messages is correctly documented in the changelog. This aligns with the PR objectives mentioned earlier.
Line range hint
1-1023: LGTM: Well-structured and informative changelogThe changelog is well-organized, providing a clear history of changes across multiple versions. It consistently categorizes changes (e.g., "State Machine Breaking", "Bug Fixes", "Features", "Improvements") and often includes links to relevant GitHub issues or pull requests. This structure makes it easy for users and developers to understand the project's evolution.
mmsqe
force-pushed
the
validate_blob
branch
from
5935f05
to
cc638bf
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- CHANGELOG.md (1 hunks)
- x/cronos/types/messages.go (1 hunks)
- x/cronos/types/messages_test.go (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- CHANGELOG.md
- x/cronos/types/messages.go
🧰 Additional context used
🪛 Gitleaks
x/cronos/types/messages_test.go
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (5)
x/cronos/types/messages_test.go (5)
4-11: LGTM: New imports added for the test function.The new imports are correctly added to support the functionality of the new test function
TestValidateMsgStoreBlockList.
17-17: LGTM: Proper test environment setup.The addition of
cmdcfg.SetBech32Prefixes(sdk.GetConfig())ensures that the Bech32 prefixes are correctly set for the test environment, which is a good practice for maintaining consistent test conditions.
62-135: LGTM: Comprehensive test coverage forMsgStoreBlockListvalidation.The new test function
TestValidateMsgStoreBlockListprovides good coverage of various scenarios:
- Valid message
- Blob exceeding maximum length
- Invalid sender address
- Decryption error
The test structure is clear and follows good practices. The use of the
agepackage for encryption testing is appropriate.🧰 Tools
🪛 Gitleaks
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
115-124: LGTM: Well-implemented encryption logic for test cases.The encryption logic is correctly implemented using the
agepackage. It's applied conditionally based on thenoEncryptflag, which allows for testing both encrypted and unencrypted scenarios. The use of a buffer to store encrypted data is efficient, and error handling is properly done withrequire.NoError.
126-132: LGTM: Thorough validation and error checking.The validation and error checking logic is well-implemented. It correctly calls
ValidateBasic()on the message and checks for expected errors, including their specific content. The differentiation between expected errors and unexpected successes ensures that the test cases are properly validated.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
x/cronos/types/messages.go (2)
203-215: Approve changes toValidateBasicmethod with a minor suggestion.The modifications to the
ValidateBasicmethod ofMsgStoreBlockListare well-implemented:
- The length check using
MaximumBlobLengthis correctly added to enforce the blob size limit.- The added comment explains the purpose of the early return with
errDummyIdentity, improving code readability.These changes enhance the robustness of the validation process for blob messages.
Consider extracting the error message for the length check into a constant for better maintainability:
+const errMsgBlobTooLarge = "block length %d must not exceed %d" func (msg *MsgStoreBlockList) ValidateBasic() error { length := len(msg.Blob) if length > MaximumBlobLength { - return errors.Wrapf(sdkerrors.ErrInvalidRequest, "block length %d must not exceed %d", length, MaximumBlobLength) + return errors.Wrapf(sdkerrors.ErrInvalidRequest, errMsgBlobTooLarge, length, MaximumBlobLength) } // ... rest of the method }This minor change would make it easier to update the error message in the future if needed.
Line range hint
1-215: Summary of changes and their impactThis PR successfully implements the max length validation for blob messages as stated in the objectives. The changes include:
- Introduction of
MaximumBlobLengthconstant (20KB limit).- Implementation of length validation in
MsgStoreBlockList.ValidateBasic().Additionally, several significant changes were made that were not explicitly mentioned in the PR objectives:
- Removal of multiple message type constants (
TypeMsgConvertVouchers,TypeMsgTransferTokens,TypeMsgTurnBridge,TypeMsgUpdatePermissions,TypeMsgStoreBlockList).- Removal of associated methods for these message types.
These removals represent a substantial change to the module's API and functionality. Please ensure that:
- These changes are thoroughly documented in the CHANGELOG.
- Any dependent modules or external systems are updated accordingly.
- The impact of these removals on the overall system architecture is well understood and communicated to the team.
Consider creating a migration guide or deprecation notice for users of the removed message types, if applicable. This will help ensure a smooth transition for any systems relying on the removed functionality.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
- CHANGELOG.md (1 hunks)
- x/cronos/types/messages.go (2 hunks)
- x/e2ee/types/msg.go (0 hunks)
💤 Files with no reviewable changes (1)
- x/e2ee/types/msg.go
🚧 Files skipped from review as they are similar to previous changes (1)
- CHANGELOG.md
🧰 Additional context used
🔇 Additional comments (2)
x/cronos/types/messages.go (2)
194-195: Approve the introduction ofMaximumBlobLengthconstant.The addition of
MaximumBlobLengthconstant with a value of 20480 (20KB) is a good practice to enforce a size limit on blob messages. This helps prevent potential issues related to processing or storing excessively large blobs.Regarding the past discussion about whether 20KB is sufficient:
- The chosen limit seems reasonable for most use cases.
- As mentioned in the previous comments, there's already a max transaction size limit in place, which provides an additional safeguard.
However, to ensure this limit is appropriate:
- Verify that 20KB is sufficient for all valid use cases of blob messages in your system.
- Consider making this value configurable (e.g., through governance or a module parameter) to allow for future adjustments if needed.
To help determine if the 20KB limit is appropriate, you can analyze the current blob sizes in your system:
#!/bin/bash # Analyze blob sizes in the codebase rg --type go -A 10 "MsgStoreBlockList" | rg "Blob:" | awk '{print length($2)}' | sort -n | uniq -cThis command will show the distribution of blob sizes, helping you confirm if the 20KB limit is suitable for your use case.
15-15: Verify the impact of removed message type constants.The removal of several message type constants (
TypeMsgConvertVouchers,TypeMsgTransferTokens,TypeMsgTurnBridge,TypeMsgUpdatePermissions,TypeMsgStoreBlockList) suggests significant changes in the module's functionality. Please ensure that:
- These message types are no longer used anywhere in the codebase.
- Any external systems or modules depending on these message types have been updated accordingly.
- The removal of these constants is documented in the CHANGELOG.
To confirm that the removed constants are not used elsewhere in the codebase, run the following command:
If this command returns any results, those occurrences need to be addressed.
mmsqe
changed the title
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (5)
x/cronos/types/messages.go (3)
205-210: Approve changes with suggestion for additional validationThe added validation logic improves the security of the
MsgStoreBlockListby ensuring the blob is properly encrypted. The comment provides clarity on the purpose of usingerrDummyIdentity.However, consider adding a maximum length check for the blob to prevent potential performance issues with extremely large blobs.
Consider adding a maximum length check for the blob before attempting decryption. For example:
func (msg *MsgStoreBlockList) ValidateBasic() error { _, err := sdk.AccAddressFromBech32(msg.From) if err != nil { return errors.Wrapf(sdkerrors.ErrInvalidAddress, "invalid sender address (%s)", err) } + if len(msg.Blob) > MaxBlobSize { + return errors.Wrapf(sdkerrors.ErrInvalidRequest, "blob size exceeds maximum allowed (%d > %d)", len(msg.Blob), MaxBlobSize) + } // skip heavy operation in Decrypt by early return with errDummyIdentity in // https://github.com/FiloSottile/age/blob/v1.1.1/age.go#L197 _, err = age.Decrypt(bytes.NewBuffer(msg.Blob), new(dummyIdentity)) if err != nil && err != errDummyIdentity { return err } return nil }Make sure to define
MaxBlobSizeas a constant at the package level.
Line range hint
1-210: Summary of changes and recommendation for thorough testingThis file has undergone significant changes, including the removal of several message types and the addition of new validation logic. While the visible changes appear appropriate, the extent of the removals suggests a larger refactoring effort.
Given the scope of these changes:
- Ensure that all affected parts of the codebase have been updated to reflect these changes.
- Update any relevant documentation to reflect the removed message types and new validation logic.
- Conduct thorough testing, including integration tests, to verify that these changes don't introduce any regressions or unexpected behavior.
- Consider updating the CHANGELOG.md to reflect these significant changes.
Consider creating a migration guide if these changes affect external integrations or APIs.
Issues Found with Removed Message Types and Methods
The removal of several message type constants and their associated methods has led to multiple references remaining in the codebase. This will likely cause compilation errors and disrupt existing functionality.
Affected Files:
x/cronos/types/codec.gox/cronos/types/messages_test.gox/cronos/types/messages.gox/cronos/types/tx.pb.gox/cronos/keeper/msg_server.gox/cronos/handler_test.gox/cronos/client/cli/tx.goapp/block_address.goPlease address these references to ensure the codebase remains consistent and functional.
🔗 Analysis chain
Line range hint
1-210: Verify impact of removed message types and methodsThe AI-generated summary indicates that several message type constants and their associated methods have been removed from this file. While these removals are not directly visible in the provided code, it's crucial to ensure that they don't negatively impact the existing functionality or cause issues in other parts of the codebase.
Please run the following script to check for any remaining references to the removed message types:
This script will help identify any remaining references to the removed message types and structs in the codebase. If any references are found, they may need to be updated or removed to maintain consistency with these changes.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for references to removed message types in the codebase # List of removed message types removed_types=( "TypeMsgConvertVouchers" "TypeMsgTransferTokens" "TypeMsgUpdateParams" "TypeMsgTurnBridge" "TypeMsgUpdatePermissions" "TypeMsgStoreBlockList" ) # Search for references to removed types for type in "${removed_types[@]}"; do echo "Searching for references to $type:" rg --type go "$type" echo done # Search for uses of removed message structs echo "Searching for uses of removed message structs:" rg --type go "MsgConvertVouchers|MsgTransferTokens|MsgTurnBridge|MsgUpdatePermissions|MsgStoreBlockList"Length of output: 32680
CHANGELOG.md (2)
Line range hint
27-36: Multiple improvements and bug fixes in dependencies.This update includes several important changes:
- Upgrade to Cosmos SDK v0.47.5 and IBC-Go v7.2.0
- Support for stateful precompiled contracts for relayer and ICA
- Removal of the Gravity module
- Increase in max block gas limit
- Support for IBC callback
These changes represent significant improvements in functionality and performance. However, they also introduce breaking changes that may require updates to dependent applications.
Consider providing a migration guide or upgrade instructions for users and developers to ensure a smooth transition to this new version.
Line range hint
1-1185: Overall assessment of v1.1.0-rc0 changesThe changes introduced in v1.1.0-rc0 represent a significant update to the Cronos blockchain. Key improvements include:
- Enhanced security with admin sender checks for MsgStoreBlockList
- Critical bug fixes for genesis migration, state synchronization, and data integrity
- Major dependency upgrades (Cosmos SDK, IBC-Go)
- Introduction of stateful precompiled contracts for relayer and ICA
- Removal of the Gravity module
- Increased max block gas limit
- Support for IBC callback
These changes should improve the overall performance, security, and functionality of the Cronos blockchain. However, the breaking changes, particularly the removal of the Gravity module and the introduction of new features, may require significant updates to dependent applications and tools.
- Provide comprehensive upgrade instructions and migration guides for node operators and developers.
- Consider a phased rollout or testnet period to ensure smooth transition and identify any potential issues before mainnet deployment.
- Communicate clearly with the community about the implications of these changes, especially the removal of the Gravity module and how it might affect existing integrations.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
- CHANGELOG.md (1 hunks)
- app/app.go (1 hunks)
- app/block_address.go (2 hunks)
- x/cronos/types/messages.go (2 hunks)
- x/cronos/types/messages_test.go (2 hunks)
🧰 Additional context used
🪛 GitHub Check: codecov/patch
app/block_address.go
[warning] 42-46: app/block_address.go#L42-L46
Added lines #L42 - L46 were not covered by tests
🪛 Gitleaks
x/cronos/types/messages_test.go
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (13)
x/cronos/types/messages_test.go (4)
17-17: LGTM: Improved test setup with Bech32 prefixes.The addition of
cmdcfg.SetBech32Prefixes(sdk.GetConfig())enhances the test environment by configuring the correct Bech32 address prefixes. This change ensures that the test conditions more accurately reflect the real blockchain environment.
65-65: Consider moving the hardcoded public key to a test constant.While the current implementation works for testing purposes, it's generally a good practice to avoid hardcoding sensitive information directly in the code. Consider moving this public key to a separate test constant or configuration file to improve maintainability and reduce the risk of accidentally exposing sensitive information.
🧰 Tools
🪛 Gitleaks
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
62-125: LGTM: Well-structured test function with good coverage.The
TestValidateMsgStoreBlockListfunction is well-implemented and covers important test cases:
- Valid message scenario
- Invalid sender address scenario
- Decryption error scenario
The use of the
agepackage for encryption testing is appropriate, and the test structure allows for easy addition of more test cases if needed in the future.🧰 Tools
🪛 Gitleaks
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
Line range hint
1-125: Summary: Improved test coverage and environment setup.The changes in this file enhance the test suite in two ways:
- The existing
TestValidateMsgUpdateTokenMappingfunction now includes proper Bech32 prefix setup, ensuring a more accurate test environment.- The new
TestValidateMsgStoreBlockListfunction provides comprehensive testing for theMsgStoreBlockListmessage type, including encryption scenarios.These improvements contribute to a more robust and reliable test suite for the Cronos blockchain types. The only minor suggestion is to consider moving the hardcoded public key to a constant for better maintainability.
🧰 Tools
🪛 Gitleaks
65-65: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
x/cronos/types/messages.go (1)
15-15: LGTM: New constant added for MsgUpdateTokenMappingThe addition of
TypeMsgUpdateTokenMappingconstant is consistent with the existing code structure and naming conventions.CHANGELOG.md (4)
18-18: New feature: Check admin sender for MsgStoreBlockList in check tx.This change adds a security check for the admin sender when processing MsgStoreBlockList transactions. This is an important security improvement that helps prevent unauthorized modifications to the block list.
Line range hint
22-23: Bug fix: Fix genesis migrate for feeibc, evm, feemarket and gravity.This fix addresses migration issues for several modules during genesis. It's crucial for ensuring proper initialization of the chain state after upgrades.
Line range hint
24-24: Bug fix: Fix lock issues when state-sync with memiavl.Resolving lock issues during state synchronization is important for maintaining data consistency and preventing potential deadlocks.
Line range hint
25-25: Bug fix: Fix memiavl's unsafe retain of the root hashes.Addressing unsafe retention of root hashes in memiavl is crucial for maintaining data integrity and preventing potential security vulnerabilities.
app/app.go (1)
1109-1109: LGTM. Verify impact on transaction processing.The addition of
app.CronosKeeper.GetParamsto theNewBlockAddressesDecoratorinitialization looks good. This change allows the decorator to access dynamic parameters from the Cronos module, which could enhance the flexibility of blocked address handling.To ensure this change doesn't introduce unexpected behavior, please run the following verification:
✅ Verification successful
Verified:
NewBlockAddressesDecoratorcorrectly integratesGetParams, ensuring blocked addresses are properly handled in transaction processing.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any changes in transaction processing related to blocked addresses # Test: Search for usage of GetParams in BlockAddressesDecorator rg --type go 'func.*BlockAddressesDecorator' -A 10 | grep 'GetParams' # Test: Look for any changes in transaction processing logic related to blocked addresses rg --type go 'func.*checkBlockedAddress' -A 20Length of output: 118
Script:
#!/bin/bash # Description: Search for all usages of GetParams in the codebase rg --type go 'GetParams' # Description: Retrieve all instances where NewBlockAddressesDecorator is initialized rg --type go 'NewBlockAddressesDecorator' -A 5 # Description: Search for any changes in transaction processing functions related to blocked addresses rg --type go 'checkBlockedAddress' -A 20Length of output: 2704
Script:
#!/bin/bash # Description: Search for functions related to blocked address validation with varied naming rg --type go 'func.*(validate|is|check).*BlockedAddress' -A 20 # Description: Retrieve all usages of BlockAddressesDecorator to ensure it's integrated correctly rg --type go 'BlockAddressesDecorator' -A 10 # Description: Search for middleware or handlers that incorporate decorators rg --type go 'middleware' -A 50 | grep 'BlockAddressesDecorator' # Description: Look for any changes in transaction processing pipelines rg --type go 'handler' -A 30 | grep -E 'BlockAddressesDecorator|BlockedMap|GetParams'Length of output: 2671
app/block_address.go (3)
16-16: Addition ofgetParamsfield toBlockAddressesDecoratorThe
getParamsfunction is added to theBlockAddressesDecoratorstruct to retrieve parameters from the context. This enhances the decorator's ability to access dynamic configuration.
19-22: UpdateNewBlockAddressesDecoratorconstructor to includegetParamsThe constructor now accepts
getParamsas a parameter, ensuring the decorator is properly initialized with access to the necessary parameters.
25-25: AssigngetParamsin the struct initializationThe assignment of
getParamswithin the constructor correctly links the parameter retrieval function to the decorator.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
app/block_address.go (2)
16-16: Consider adding documentation for thegetParamsfieldAdding a comment to explain the purpose of the
getParamsfunction within theBlockAddressesDecoratorstruct will improve code readability and maintainability.
19-22: Update function documentation to include the new parameterThe
NewBlockAddressesDecoratorfunction now accepts agetParamsparameter. Please update the function's documentation to describe this parameter and its role in the decorator's behavior.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- app/block_address.go (2 hunks)
🧰 Additional context used
🔇 Additional comments (1)
app/block_address.go (1)
43-50: Authorization logic correctly restricts access toMsgStoreBlockListmessagesThe added authorization check ensures that only the
CronosAdmincan submitMsgStoreBlockListmessages. This implementation properly enforces the required access control.
This reverts commit f7405ce.
7c3ac87
👮🏻👮🏻👮🏻 !!!! REFERENCE THE PROBLEM YOUR ARE SOLVING IN THE PR TITLE AND DESCRIBE YOUR SOLUTION HERE !!!! DO NOT FORGET !!!! 👮🏻👮🏻👮🏻
PR Checklist:
make)make test)go fmt)golangci-lint run)go list -json -m all | nancy sleuth)Thank you for your code, it's appreciated! :)
Summary by CodeRabbit
New Features
MsgStoreBlockListmessages.MsgUpdateTokenMapping.Bug Fixes
MsgStoreBlockListmessage type.ethermintAPI and corrections to account queries and multisig account handling.Tests
MsgStoreBlockList, including scenarios for valid inputs and error handling.