-
Notifications
You must be signed in to change notification settings - Fork 110
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
feat: Solana relayer (fee payer) key importer, encryption and decryption #2673
Conversation
|
GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
---|---|---|---|---|---|
13340122 | Triggered | Generic High Entropy Secret | 5da629e | cmd/zetaclientd/import_relayer_keys.go | View secret |
13340122 | Triggered | Generic High Entropy Secret | 66b7027 | zetaclient/chains/solana/signer/signer_test.go | View secret |
13340122 | Triggered | Generic High Entropy Secret | 66b7027 | zetaclient/chains/solana/signer/signer_test.go | View secret |
13340122 | Triggered | Generic High Entropy Secret | 98f041a | cmd/zetaclientd/import_relayer_keys.go | View secret |
13392123 | Triggered | Generic High Entropy Secret | 66b7027 | zetaclient/chains/solana/signer/signer_test.go | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughWalkthroughThe recent changes significantly refactor the ZetaChain codebase to enhance the management of relayer keys, particularly for the Solana blockchain. Key functionalities related to the encryption and handling of relayer keys have been introduced, alongside improvements to configuration structures and command-line utilities. This refactoring streamlines key management processes while improving code maintainability and readability, reflecting a strategic shift in the application's architecture towards more robust and secure operations. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI
participant Config
participant RelayerKey
participant Signer
User->>CLI: Import relayer key
CLI->>Config: Set RelayerKeyPath
CLI->>RelayerKey: Load relayer key
RelayerKey->>Config: Retrieve key
CLI->>Signer: Use relayer key for signing transactions
sequenceDiagram
participant User
participant CLI
participant AES
participant File
User->>CLI: Encrypt TSS file
CLI->>AES: Encrypt using AES-256-GCM
AES->>File: Save encrypted data
File->>CLI: Confirm save
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 as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
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.
Actionable comments posted: 13
Outside diff range, codebase verification and nitpick comments (10)
pkg/os/path.go (1)
10-24
: LGTM! Consider enhancing the documentation for clarity.The
ExpandHomeDir
function is well-implemented. Consider expanding the documentation to clarify the behavior for paths with a leading tilde.- // ExpandHomeDir expands a leading tilde in the path to the home directory of the current user. + // ExpandHomeDir expands a leading tilde (~) in the path to the home directory of the current user.pkg/crypto/aes256_gcm.go (1)
32-54
: Enhance Error Logging inDecryptAES256GCMBase64
FunctionThe
DecryptAES256GCMBase64
function currently wraps errors but does not log them. To improve debugging and error tracking, consider adding logging for any errors that occur during decryption. This will help in identifying issues without exposing sensitive information.
- Add logging for errors in the
DecryptAES256GCMBase64
function to ensure proper tracking of decryption failures.Analysis chain
Check for proper error handling and logging.
The
DecryptAES256GCMBase64
function should ensure that any errors, especially those related to decryption failures, are logged appropriately for debugging purposes without exposing sensitive information.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify if error logging is implemented properly in the codebase. # Test: Search for logging practices in the codebase. rg --type go 'log\.(Error|Warn|Info|Debug|Fatal)'Length of output: 9186
zetaclient/chains/solana/signer/withdraw.go (1)
Line range hint
92-101
:
Clarify the signing logic for maintainability.The logic for signing the transaction with the relayer key is appropriate. Consider adding a brief comment to explain why the relayer key is used here, which would improve code maintainability and readability.
+ // Use the relayer key to sign the transaction as per the updated security model.
zetaclient/config/types.go (1)
82-82
: Consider using snake_case for JSON fields.The JSON field
RelayerKeyPath
should follow the snake_case convention as noted in the TODO comment above.- RelayerKeyPath string `json:"RelayerKeyPath"` + RelayerKeyPath string `json:"relayer_key_path"`cmd/zetaclientd/import_relayer_keys.go (6)
55-59
: Handle potential errors when expanding home directories.The error from
zetaos.ExpandHomeDir
is logged, but the application exits immediately after logging. Consider providing more context in the log message or handling the error more gracefully.- log.Fatal().Err(err).Msg("failed to resolve default relayer key path") + log.Fatal().Err(err).Msgf("failed to resolve default relayer key path: %s", defaultRelayerKeyPath)
79-84
: Validate input arguments early.The validation of the
privateKey
andpassword
could be done earlier, potentially before any other operations, to fail fast and avoid unnecessary computations.Consider moving this validation to the beginning of the
ImportRelayerKey
function.
93-97
: Ensure directory creation errors are properly handled.The
os.MkdirAll
function is used to create directories with specific permissions. Ensure that any errors are logged with sufficient context to aid in debugging.- return errors.Wrapf(err, "failed to create relayer key path: %s", keyPath) + log.Error().Err(err).Msgf("failed to create relayer key path: %s", keyPath)
100-105
: Prevent potential file overwrite issues.The check for existing files is good practice. Ensure that users are adequately informed about the implications of overwriting existing files.
Consider adding a user prompt or a flag to allow overwriting if necessary.
120-123
: Ensure secure file permissions.The file is created with owner read/write permissions, which is good. Ensure that this is documented and that users are aware of the security implications.
Consider adding a comment or documentation about the chosen file permissions.
161-177
: Improve error handling in path resolution.The
resolveRelayerKeyPath
function handles errors but could provide more context in its error messages to aid debugging.- return "", "", errors.Wrap(err, "failed to resolve relayer key path") + return "", "", errors.Wrapf(err, "failed to resolve relayer key path: %s", relayerKeyPath)
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (23)
- cmd/zetaclientd/encrypt_tss.go (3 hunks)
- cmd/zetaclientd/import_relayer_keys.go (1 hunks)
- cmd/zetaclientd/init.go (4 hunks)
- cmd/zetae2e/config/localnet.yml (1 hunks)
- contrib/localnet/orchestrator/Dockerfile.fastbuild (1 hunks)
- contrib/localnet/orchestrator/start-zetae2e.sh (1 hunks)
- contrib/localnet/scripts/start-zetaclientd.sh (3 hunks)
- e2e/config/config.go (2 hunks)
- pkg/chains/chain.go (1 hunks)
- pkg/chains/chain_test.go (1 hunks)
- pkg/crypto/aes256_gcm.go (1 hunks)
- pkg/crypto/aes256_gcm_test.go (1 hunks)
- pkg/os/path.go (1 hunks)
- pkg/os/path_test.go (1 hunks)
- rpc/namespaces/ethereum/debug/api.go (2 hunks)
- rpc/namespaces/ethereum/debug/trace.go (2 hunks)
- rpc/namespaces/ethereum/debug/utils.go (2 hunks)
- server/start.go (2 hunks)
- zetaclient/chains/solana/signer/signer.go (5 hunks)
- zetaclient/chains/solana/signer/withdraw.go (3 hunks)
- zetaclient/config/types.go (3 hunks)
- zetaclient/keys/relayer_keys.go (1 hunks)
- zetaclient/orchestrator/bootstrap.go (2 hunks)
Additional context used
Path-based instructions (21)
pkg/os/path.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.cmd/zetaclientd/encrypt_tss.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.rpc/namespaces/ethereum/debug/utils.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.pkg/os/path_test.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.rpc/namespaces/ethereum/debug/trace.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.pkg/crypto/aes256_gcm.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.zetaclient/keys/relayer_keys.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.zetaclient/chains/solana/signer/withdraw.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.cmd/zetaclientd/init.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.contrib/localnet/scripts/start-zetaclientd.sh (1)
Pattern
**/*.sh
: Review the shell scripts, point out issues relative to security, performance, and maintainability.zetaclient/config/types.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.pkg/crypto/aes256_gcm_test.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.zetaclient/chains/solana/signer/signer.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.cmd/zetaclientd/import_relayer_keys.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.pkg/chains/chain.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.contrib/localnet/orchestrator/start-zetae2e.sh (1)
Pattern
**/*.sh
: Review the shell scripts, point out issues relative to security, performance, and maintainability.zetaclient/orchestrator/bootstrap.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.rpc/namespaces/ethereum/debug/api.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.pkg/chains/chain_test.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/config/config.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.server/start.go (1)
Pattern
**/*.go
: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
Gitleaks
cmd/zetae2e/config/localnet.yml
60-60: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
63-63: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
cmd/zetaclientd/import_relayer_keys.go
21-21: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
Additional comments not posted (30)
contrib/localnet/orchestrator/Dockerfile.fastbuild (1)
3-3
: LGTM! Verify the compatibility of the new Solana base image.The addition of the Solana base image and the Solana CLI tool enhances the orchestrator's capabilities. Ensure that the new base image is compatible with the existing setup.
Also applies to: 11-11
pkg/os/path.go (1)
26-33
: LGTM! TheFileExists
function is efficient and clear.The implementation correctly checks for file existence and handles errors appropriately.
cmd/zetaclientd/encrypt_tss.go (1)
Line range hint
25-43
:
LGTM! Verify the integration with the new encryption utility.The refactoring of
EncryptTSSFile
enhances readability and maintainability. Ensure that thecrypto.EncryptAES256GCM
utility function is correctly integrated and tested.Verification successful
Integration Verified:
EncryptAES256GCM
is Correctly Integrated withEncryptTSSFile
The
EncryptAES256GCM
function is properly implemented and integrated within theEncryptTSSFile
function. The function uses AES encryption in GCM mode, ensuring secure encryption of the provided data. No further issues were found regarding this integration.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the integration of `crypto.EncryptAES256GCM` with the `EncryptTSSFile` function. # Test: Check for the implementation of `EncryptAES256GCM` in the `crypto` package. ast-grep --lang go --pattern $'func EncryptAES256GCM($_, $_) ($_, error) { $$$ }'Length of output: 1244
rpc/namespaces/ethereum/debug/utils.go (1)
39-39
: Verify the behavior ofzetaos.ExpandHomeDir
.The function
ExpandHomeDir
from thezetaos
package replaces the local implementation. Ensure that it correctly handles all edge cases related to home directory expansion.Verification successful
Verification of
zetaos.ExpandHomeDir
FunctionalityThe
ExpandHomeDir
function inpkg/os/path.go
correctly handles the expansion of home directory paths by checking if the path starts with~
,~/
, or~\
. It retrieves the current user's home directory and joins it with the rest of the path. The function also handles errors in user retrieval and cleans the resulting path before returning it. This implementation appears robust for the intended purpose.
- The function handles basic cases for home directory expansion.
- It includes error handling for user retrieval failures.
No further issues were found with this implementation.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the behavior of `zetaos.ExpandHomeDir`. # Test: Search for the function implementation. Expect: Correct handling of home directory paths. ast-grep --lang go --pattern $'func ExpandHomeDir($_) ($_, $_) { $$$ }' | rg --context 5 'ExpandHomeDir'Length of output: 387
Script:
#!/bin/bash # Extract the full implementation of the ExpandHomeDir function to verify its behavior. ast-grep --lang go --pattern $'func ExpandHomeDir($_) ($_, $_) { $$$ }' --outputLength of output: 283
Script:
#!/bin/bash # Correctly extract the full implementation of the ExpandHomeDir function for analysis. ast-grep --lang go --pattern $'func ExpandHomeDir($_) ($_, $_) { $$$ }'Length of output: 580
pkg/os/path_test.go (2)
14-49
: Comprehensive tests for home directory resolution.The test cases for
ExpandHomeDir
are well-structured and cover various scenarios, ensuring robust validation of the functionality.
51-83
: Effective tests for file existence checks.The test cases for
FileExists
effectively verify the function's behavior for both existing and non-existing files.rpc/namespaces/ethereum/debug/trace.go (1)
42-42
: Ensure consistent behavior ofzetaos.ExpandHomeDir
.The
ExpandHomeDir
function from thezetaos
package is used here. Verify that it handles path expansion consistently across different scenarios.Verification successful
Consistent Behavior of
zetaos.ExpandHomeDir
VerifiedThe
ExpandHomeDir
function consistently handles the expansion of home directory paths. It checks for common prefixes (~
,~/
,~\
) and usesuser.Current()
to retrieve the home directory. Errors are handled gracefully, and the path is cleaned before returning. No issues found.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the behavior of `zetaos.ExpandHomeDir` in the context of `StartGoTrace`. # Test: Search for the function implementation. Expect: Consistent handling of home directory paths. ast-grep --lang go --pattern $'func ExpandHomeDir($_) ($_, $_) { $$$ }' | rg --context 5 'ExpandHomeDir'Length of output: 387
Script:
#!/bin/bash # Description: Retrieve the full implementation of `ExpandHomeDir` to verify its behavior. ast-grep --lang go --pattern 'func ExpandHomeDir($_) ($_, $_) { $$$ }'Length of output: 580
pkg/crypto/aes256_gcm.go (1)
14-30
: Ensure secure key management practices.The
EncryptAES256GCMBase64
function handles encryption keys as strings, which can be insecure if not managed properly. Ensure that keys are stored and transmitted securely, possibly using environment variables or secure vaults.zetaclient/keys/relayer_keys.go (1)
21-24
: Ensure sensitive data is protected.The
RelayerKey
struct contains a private key. Ensure that this data is handled securely, especially when logged or transmitted.Verification successful
Ensure Secure Handling of
RelayerKey
inReadRelayerKeyFromFile
FunctionThe
ReadRelayerKeyFromFile
function returns aRelayerKey
, which contains sensitive data. While there are no direct logging or transmission concerns found, ensure that:
- The private key is not inadvertently exposed in logs or error messages.
- Access to the file containing the key is properly secured.
- Consider encrypting the key at rest and in transit, if applicable.
These precautions will help protect sensitive data effectively.
- Location to Review:
zetaclient/keys/relayer_keys.go:67-95
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify if there are any logging practices that might expose sensitive data. # Test: Search for any logging statements involving `RelayerKey`. rg --type go 'log\..*\(.*RelayerKey.*\)'Length of output: 42
Script:
#!/bin/bash # Description: Check for any error handling or transmission of `RelayerKey`. # Test: Search for any error handling involving `RelayerKey`. rg --type go 'errors\..*\(.*RelayerKey.*\)' # Test: Search for any instances where `RelayerKey` might be transmitted over networks. rg --type go 'http\..*\(.*RelayerKey.*\)'Length of output: 190
Script:
#!/bin/bash # Description: Check for functions returning `RelayerKey` and ensure they handle the private key securely. # Test: Search for functions that return `RelayerKey`. ast-grep --lang go --pattern 'func $_($_) (RelayerKey, $_) { $$$ }'Length of output: 1949
zetaclient/chains/solana/signer/withdraw.go (1)
Line range hint
50-68
:
Ensure correct usage of the relayer key.The change to use
signer.relayerKey
instead ofsigner.solanaFeePayerKey
is correct given the context. Ensure that this change is reflected consistently across the codebase where this function is used.Verification successful
Verified: Correct usage of
signer.relayerKey
inwithdraw.go
.The change to use
signer.relayerKey
is correctly applied within thewithdraw.go
file, and no inconsistencies were found in other parts of the codebase. This indicates that the update is well-contained and appropriate for its intended purpose.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify usage of `signer.relayerKey` across the codebase. # Test: Search for usage of `signer.relayerKey`. Expect: Consistent usage in the context of transaction signing. rg --type go 'signer\.relayerKey'Length of output: 109
cmd/zetaclientd/init.go (3)
39-39
: Rename field toRelayerKeyPath
.The renaming of
SolanaKey
toRelayerKeyPath
accurately reflects the new focus on relayer key management. Ensure that this change is consistently applied throughout the codebase.
112-112
: AssignRelayerKeyPath
in configuration.The assignment of
RelayerKeyPath
toconfigData
is appropriate. Ensure that this path is correctly utilized in the application logic where relayer keys are required.
73-74
: Update command-line flag for relayer keys.The new command-line flag
--relayer-key-path
is correctly introduced. Verify that this flag is documented in any user-facing documentation and that it is used correctly in all relevant scripts and configurations.contrib/localnet/scripts/start-zetaclientd.sh (2)
82-82
: Create relayer key file for Solana.The call to
create_relayer_key_file
for Solana is appropriate. Ensure that the key file is correctly used in subsequent operations and that any errors during creation are handled gracefully.
105-105
: Create relayer key file for Solana in non-zero hosts.The logic to create the relayer key file for non-zero hosts is appropriate. Ensure that this logic is consistent with the overall initialization process and that any errors are logged and handled.
zetaclient/config/types.go (1)
162-166
: Ensure consistent use of mutex for thread safety.The
GetRelayerKeyPath
method correctly uses a read lock for thread safety, which is consistent with the other methods in theConfig
struct.pkg/crypto/aes256_gcm_test.go (1)
1-187
: Comprehensive test coverage for AES-256-GCM functions.The test cases cover a wide range of scenarios, ensuring robustness of the encryption and decryption functions. The use of table-driven tests and
require
assertions is commendable.zetaclient/chains/solana/signer/signer.go (2)
32-33
: Update reflects new role of the relayer key.The renaming of
solanaFeePayerKey
torelayerKey
accurately reflects its new purpose, improving code clarity.
Line range hint
48-74
:
Ensure correct handling of relayer key inNewSigner
.The
NewSigner
function correctly constructs the Solana private key from therelayerKey
. Ensure that all dependent code is updated to handlekeys.RelayerKey
appropriately.Verification successful
Verification of
NewSigner
Handling ofkeys.RelayerKey
: SuccessfulThe
NewSigner
function for the Solana signer is correctly usingkeys.RelayerKey
as intended in thebootstrap.go
file. The implementation aligns with the review comment's requirements, ensuring that the relayer key is handled appropriately. No further updates are necessary for this aspect of the code.
- Location Confirmed:
zetaclient/orchestrator/bootstrap.go
usessolanasigner.NewSigner
withrelayerKey
.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all instances of `NewSigner` are updated to use `keys.RelayerKey`. # Test: Search for `NewSigner` usage. Expect: Only occurrences with `keys.RelayerKey`. rg --type go -A 3 $'NewSigner'Length of output: 5337
pkg/chains/chain.go (1)
150-154
: Ensure map access safety.The
GetNetworkName
function uses a map to retrieve network names. Ensure that the map is initialized and populated correctly elsewhere in the codebase.Check that
Network_name
is properly initialized and populated.Verification successful
Map Initialization and Population Verified
The
Network_name
map is properly initialized and populated inpkg/chains/chains.pb.go
. This ensures safe access in theGetNetworkName
function. No further action is required.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that `Network_name` is initialized and populated correctly. # Test: Search for the initialization and population of `Network_name`. Expect: Valid map initialization and population. rg --type go --context 5 'Network_name\s*=\s*map\[int32\]string'Length of output: 520
contrib/localnet/orchestrator/start-zetae2e.sh (2)
47-92
: Suppressing command output improves script cleanliness.Redirecting output to
/dev/null
is a good practice for reducing unnecessary console output. Ensure that important logs are not suppressed.
94-104
: Securely handle Solana account funding.The script funds Solana relayer accounts. Ensure that sensitive information, such as private keys, is not exposed in the script or logs.
Check that no sensitive information is exposed in the configuration or logs.
zetaclient/orchestrator/bootstrap.go (1)
166-169
: Change to relayer key loading approved.The switch from loading a Solana private key to a relayer key enhances the security and flexibility of key management. Ensure that the
LoadRelayerKey
function is correctly implemented and used throughout the codebase.rpc/namespaces/ethereum/debug/api.go (1)
203-203
: Integration with Zeta Chain utilities approved.The use of
zetaos.ExpandHomeDir
enhances compatibility with Zeta Chain's ecosystem. Ensure that this function is consistently used where applicable.Verification successful
Consistent Usage of
zetaos.ExpandHomeDir
VerifiedThe function
zetaos.ExpandHomeDir
is consistently used across various files, ensuring compatibility with Zeta Chain's ecosystem. This integration appears to be implemented as intended.
- Files with usage:
zetaclient/keys/relayer_keys.go
server/start.go
rpc/namespaces/ethereum/debug/trace.go
rpc/namespaces/ethereum/debug/utils.go
rpc/namespaces/ethereum/debug/api.go
pkg/os/path_test.go
cmd/zetaclientd/import_relayer_keys.go
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of `zetaos.ExpandHomeDir` in the codebase. # Test: Search for the function usage. Expect: Consistent usage across all relevant files. rg --type go 'zetaos.ExpandHomeDir'Length of output: 693
pkg/chains/chain_test.go (2)
399-405
: New testTestGetNetworkName
approved.This test effectively validates the
GetNetworkName
function, enhancing test coverage for network identification.
411-411
: Modification inTestGetChainFromChainID
approved.The change to focus on the
found
boolean improves the clarity and intent of the test.e2e/config/config.go (3)
44-50
: Integration ofObserverRelayerAccounts
field.The addition of the
ObserverRelayerAccounts
field in theConfig
struct is well-integrated and enhances multi-chain account management. Ensure that this field is documented in any relevant configuration documentation.
58-59
: Integration of Solana fields inAccount
struct.The
SolanaAddress
andSolanaPrivateKey
fields are well-integrated into theAccount
struct, supporting Solana account management. Consider adding validation for these fields similar to existing EVM address validation.
81-85
: Design ofObserverRelayerAccounts
struct.The
ObserverRelayerAccounts
struct is well-designed for managing observer relayer accounts. Ensure that its usage is consistent across the codebase to maintain clarity and organization.server/start.go (1)
340-342
: Refactoring to usezetaos.ExpandHomeDir
.The refactoring to use
zetaos.ExpandHomeDir
instead ofethdebug.ExpandHome
aligns with the architectural direction of consolidating functionality under thezetaos
package. Verify that this change maintains the intended functionality and does not introduce regressions.
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.
Did a first review round. Can you add a description with the context & purpose of these changes?
…t-solana-fee-payer-key
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #2673 +/- ##
===========================================
+ Coverage 71.02% 71.25% +0.22%
===========================================
Files 346 351 +5
Lines 18807 18982 +175
===========================================
+ Hits 13358 13525 +167
+ Misses 4858 4853 -5
- Partials 591 604 +13
|
I updated the description of the PR. The goal is to formalize the usage of relayer key. |
…key validation when importing
…t-solana-fee-payer-key
!!!WARNING!!! Be very careful about using Only suppress a single rule (or a specific set of rules) within a section of code, while continuing to scan for other problems. To do this, you can list the rule(s) to be suppressed within the #nosec annotation, e.g: /* #nosec G401 */ or //#nosec G201 G202 G203 Pay extra attention to the way |
…ion (#2673) * configure observer relayer key for Solana; remove hardcoded solana test key from zetaclient code * implementation of relayer key importer, encryption and decryption * integrate relayer key into E2E and Solana signer * add relayer_key_balance metrics and unit tests * use TrimSpace to trim password * add changelog entry * use relayer account array in E2E config; a few renaming; add private key validation when importing * fix linter * remove GetNetworkName method for simplification * added PromptPassword method to prompt single password * use network name as map index to store relayer key passwords * moved relayer passwords to chain registry * airdrop SOL token only if solana local node is available --------- Co-authored-by: Lucas Bertrand <lucas.bertrand.22@gmail.com>
* feat: parse inscription like witness data (#2524) * parse inscription like witness data * more comment * remove unused code * Update zetaclient/chains/bitcoin/tx_script.go Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> * Update zetaclient/chains/bitcoin/observer/inbound.go Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> * Update zetaclient/chains/bitcoin/tx_script.go Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> * Update zetaclient/chains/bitcoin/tx_script.go Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> * pull origin * Update zetaclient/chains/bitcoin/observer/inbound.go Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> * review feedbacks * update review feedbacks * update make generate * fix linter * remove over flow * Update zetaclient/chains/bitcoin/observer/inbound.go Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> * Update zetaclient/chains/bitcoin/tokenizer.go Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> * Update zetaclient/chains/bitcoin/tokenizer.go Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> * Update zetaclient/chains/bitcoin/tokenizer.go Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> * Update zetaclient/chains/bitcoin/tokenizer.go Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> * update review feedback * update code commnet * update comment * more comments * Update changelog.md --------- Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> fix version * feat: detect memo in btc txn from OP_RETURN and inscription (#2533) * parse inscription like witness data * more comment * remove unused code * parse inscription * Update zetaclient/chains/bitcoin/tx_script.go Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> * Update zetaclient/chains/bitcoin/observer/inbound.go Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> * Update zetaclient/chains/bitcoin/tx_script.go Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> * Update zetaclient/chains/bitcoin/tx_script.go Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> * pull origin * Update zetaclient/chains/bitcoin/observer/inbound.go Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> * review feedbacks * update review feedbacks * add mainnet txn * Update zetaclient/chains/bitcoin/tx_script.go Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> * parse inscription like witness data * more comment * remove unused code * Update zetaclient/chains/bitcoin/tx_script.go Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> * Update zetaclient/chains/bitcoin/observer/inbound.go Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> * Update zetaclient/chains/bitcoin/tx_script.go Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> * Update zetaclient/chains/bitcoin/tx_script.go Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> * pull origin * Update zetaclient/chains/bitcoin/observer/inbound.go Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> * review feedbacks * update review feedbacks * update make generate * fix linter * remove over flow * Update zetaclient/chains/bitcoin/observer/inbound.go Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> * Update zetaclient/chains/bitcoin/tokenizer.go Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> * Update zetaclient/chains/bitcoin/tokenizer.go Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> * Update zetaclient/chains/bitcoin/tokenizer.go Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> * Update zetaclient/chains/bitcoin/tokenizer.go Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> * update review feedback * update code commnet * update comment * more comments * Update changelog.md * Update zetaclient/chains/bitcoin/observer/inbound.go Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> * Update zetaclient/chains/bitcoin/observer/inbound.go Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> * clean up * format code --------- Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> * refactor(zetaclient)!: improve AppContext (#2568) * Implement chain registry * Rewrite test-cases for AppContext * Drop `supplychecker` * Refactor app ctx Update worker * Refactor orchestrator * Refactor observer&signer; DROP postBlockHeaders * Fix test cases [1] * Update changelog * Allow Zeta Chain in appContext; address PR comments [1] * Fix app context update * Check for `chain.IsZeta()` * Add AppContext.FilterChains * Fix test cases [2] * Fix test cases [3] * Address PR comments [1] * Address PR comments [2] * Add tests for `slices` * Fix e2e tests [1] * Fix e2e tests [2] * Resolve conflicts, converge codebase between PRs * Add lodash; remove slices pkg * Address PR comments * Minor logging fix * Address PR comments tmp * feat(zetaclient): add generic rpc metrics (#2597) * feat(zetaclient): add generic rpc metrics * feedback * changelog * fmt * fix(zetaclient): use name in pending tx metric (#2642) * feat(pkg): add `ticker` package (#2617) * Add `pkg/ticker` * Sample ticker usage in evm observer * Change naming * Address PR comments * Address PR comments * feat(zetaclient)!: Add support for EIP-1559 gas fees (#2634) * Add Gas struct * Add EIP-1559 fees * Update changelog * Add test cases for legacy vs dynamicFee txs * Fix typo; Add E2E coverage * Address PR comments * Address PR comments * Use gasFeeCap formula * Revert "Use gasFeeCap formula" This reverts commit 2260925. * Address PR comments * Fix e2e upgrade tests * fix: adjust evm outbound tracker reporter to avoid submitting invalid hashes (#2628) * refactor and fix evm outbound tracker reporter to avoid invalid hashes; print log when outbound tracker is full of invalid hashes * add changelog entry * used predefined log fields * remove repeated fields information from log message; Devops team would configure Datadog to show the fields * remove redundant fields in log message; unified logs * remove pending transaction map from observer; the outbound tracker reporter will no longer report pending hash * use bg.Work() to launch outbound tracker reporter goroutines * bring the checking EnsureNoTrackers() back * add more rationale to EVM outbound tracker submission * sync observer and signers without wait on startup * try fixing tss migration E2E failure by increase timeout * feat: Solana relayer (fee payer) key importer, encryption and decryption (#2673) * configure observer relayer key for Solana; remove hardcoded solana test key from zetaclient code * implementation of relayer key importer, encryption and decryption * integrate relayer key into E2E and Solana signer * add relayer_key_balance metrics and unit tests * use TrimSpace to trim password * add changelog entry * use relayer account array in E2E config; a few renaming; add private key validation when importing * fix linter * remove GetNetworkName method for simplification * added PromptPassword method to prompt single password * use network name as map index to store relayer key passwords * moved relayer passwords to chain registry * airdrop SOL token only if solana local node is available --------- Co-authored-by: Lucas Bertrand <lucas.bertrand.22@gmail.com> * ci: Set Docker Workflow to use Go 1.22 (#2722) * Set go 1.22.2 * Set go 1.22.2 * Set go 1.22 * Set go 1.22 * Refactor contrib/rpc and contrib/docker-scripts to use snapshots API (#2724) Co-authored-by: Julian Rubino <julian@zetachain.com> --------- Co-authored-by: dev-bitSmiley <153714963+bitSmiley@users.noreply.github.com> Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: Francisco de Borja Aranda Castillejo <me@fbac.dev> Co-authored-by: Charlie Chen <34498985+ws4charlie@users.noreply.github.com> Co-authored-by: Lucas Bertrand <lucas.bertrand.22@gmail.com> Co-authored-by: Charlie <31941002+CharlieMc0@users.noreply.github.com> Co-authored-by: Julian Rubino <julian.rubino0@gmail.com> Co-authored-by: Julian Rubino <julian@zetachain.com>
Description
The goals of this PR:
localnet.yml
to inject solana E2E test keys.The changes of this PR:
import-relayer-key
to import and encrypt relayer private keyrelayer-address
to decrypt and show imported relayer addressrelayer_key_balance
.Closes: #2614
Closes: #2606
How Has This Been Tested?
Summary by CodeRabbit
New Features
Bug Fixes
Refactor
Signer
methods to reflect changes in the key management approach.Tests
Documentation