Skip to content
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

Report of Confusing Behavior in Namada Transfer Command #2881

Closed
tphat2616 opened this issue Mar 11, 2024 · 2 comments
Closed

Report of Confusing Behavior in Namada Transfer Command #2881

tphat2616 opened this issue Mar 11, 2024 · 2 comments
Labels
bug Something isn't working UX

Comments

@tphat2616
Copy link

Title:
Finding Security Vulnerabilities

Summery:
While utilizing the transfer command with the "--source multi" and "--target phat" options, along with the "--signing-keys phat,teo" parameter, I encountered an issue. Specifically, during the process, when the source account is initialized with a threshold of 1, the transfer command prompts for only one account signature. However, it erroneously accepts any input for the second signature prompt, even without the correct password. This behavior might confuse users as it implies that the second key is not essential for the transaction.

Here is a summary of the encountered scenario:

Command:namadac transfer --source multi --target phat --token naan --amount 1 --signing-keys phat,teo

Response from the console:Enter your decryption password: [Correct password for key 1]
Enter your decryption password: [Any input is accepted for key 2]
Transaction added to mempool.

I believe addressing this issue could enhance the clarity and security of the transfer process for users. It's essential to ensure that when the source account is initialized with a threshold of 1, only one account signature should be required during the transfer process.

@tphat2616 tphat2616 added the bug Something isn't working label Mar 11, 2024
@quangtuyen88
Copy link

quangtuyen88 commented Mar 11, 2024

This issue has been reported and will be fixed in this ticket #2747

@tphat2616
Copy link
Author

This issue has been reported and will be fixed in this ticket #2747

This PR has nothing to relate with my bug at all.

@cwgoes cwgoes added the UX label May 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working UX
Projects
None yet
Development

No branches or pull requests

4 participants