-
Notifications
You must be signed in to change notification settings - Fork 3
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: signal bits and authority outputs #67
base: dev
Are you sure you want to change the base?
Conversation
Reference for reviewers: Macros
UI Macros are a separate category since they are used to organize the screens and user interaction, it works by building steps (screens) and flows (similar to menus, with multiple screens). User interaction on a step is interpreted as pressing both buttons at the same time.
|
} | ||
|
||
bool is_mint_authority(uint8_t token_data, uint64_t value) { | ||
return is_authority_output(token_data) && value == MINT_AUTHORITY_MASK; |
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 think this should be && (value & MINT_AUTHORITY_MASK) > 0
, shouldn't it?
The same for melt
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 problem with this is the Mint+Melt case, where an output is authority for both mint and melt.
This edge case may be complicated for the user so I decided not to allow this case in the Ledger app.
Do you think we should allow this case as a special Mint+Melt output
on the UI?
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 think it's ok to limit this but I don't see as this complicated, we could show exactly as you wrote: Mint + Melt
or Mint and Melt
.
If we decide to leave this out, we should just make clear in the design
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’ve reopened this thread to address the issue. I believe we need to correctly implement the logic in these methods, while managing the mint and melt permissions elsewhere. The current approach might be misleading and prone to errors during future updates.
Regarding the minting and melting capabilities, I found the previous discussion a bit confusing. It doesn’t seem possible to mint and melt the same token simultaneously. So, the real question is whether a token authority should have both capabilities. I believe they should.
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 forgot to put the reason the discussion was closed, this was meant to be discussed and implemented on another PR.
We can block this PR to solve this issue but this can easily be implemented later depending on the decision.
…od-01 * origin/dev: chore: update linter version chore: update CI (#77) feat: use correct size limit fix: code scanning [auto] Add guideline enforcer [auto] Add manifest [auto]: add PR template
dd6f3ca
to
7068697
Compare
} | ||
|
||
bool is_mint_authority(uint8_t token_data, uint64_t value) { | ||
return is_authority_output(token_data) && value == MINT_AUTHORITY_MASK; |
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’ve reopened this thread to address the issue. I believe we need to correctly implement the logic in these methods, while managing the mint and melt permissions elsewhere. The current approach might be misleading and prone to errors during future updates.
Regarding the minting and melting capabilities, I found the previous discussion a bit confusing. It doesn’t seem possible to mint and melt the same token simultaneously. So, the real question is whether a token authority should have both capabilities. I believe they should.
} | ||
|
||
bool is_melt_authority(uint8_t token_data, uint64_t value) { | ||
return is_authority_output(token_data) && value == MELT_AUTHORITY_MASK; |
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.
Same here!
@@ -80,6 +80,29 @@ def test_qa_sign_tx_custom_tokens(cmd): | |||
signatures = cmd.sign_tx(tx) | |||
|
|||
|
|||
def test_qa_sign_tx_with_token(cmd): |
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 can't find where you used this function.
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 QA file is not meant to run on the automated tests.
The idea of these tests is to run with a dev so the dev can check that all screens (UI/UX) are working as intended.
While we do not have a QA for the Ledger I like to keep this file updated with new methods and features since I also use this qa.py
for simple tests.
@@ -94,8 +117,8 @@ def test_qa_sign_tx_with_authority(cmd): | |||
TxOutput(fake.pyint(1), fake_script()), | |||
] | |||
tx = Transaction(0, 1, [token.uid], inputs, outputs) | |||
print("QA::sign_tx_with_authority::token:", str(token)) | |||
print("QA::sign_tx_with_authority::tx:", str(tx)) | |||
print("QA::sign_tx_with_aauthority::token:", str(token)) |
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.
Typo?
print("QA::sign_tx_with_authority::token:", str(token)) | ||
print("QA::sign_tx_with_authority::tx:", str(tx)) | ||
print("QA::sign_tx_with_aauthority::token:", str(token)) | ||
print("QA::sign_tx_with_aauthority::tx:", str(tx)) |
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.
Typo?
|
||
def test_sign_tx_with_authority(cmd, public_key_bytes): | ||
token = fake_token() | ||
inputs = [ |
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 can't find the mint and melt authorities. Where are they?
I was expecting to find the following tests:
- Minting tokens.
- Melting tokens.
- Destroying mint authority.
- Destroying melt authority.
- Delegating mint authority.
- Delegating melt authority.
Each case with Mint, Melt, and Mint+Melt authorities.
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 will also be discussed later but a Mint Transaction is a transaction with:
- Mint Authority input
- HTR input
- Minted Token output
- Optional: Mint authority output
- Optional: HTR change output
Since inputs are not validated, a transaction with a mint authority output and a valid token is indistinguishable from a Mint transaction, same with Melt authorities.
So testing that we can show and confirm a Mint or Melt output is enough to test a Mint or Melt operation.
The same logic applies with Destroy and Delegate.
} else { | ||
// This authority is unknown, so we treat it as invalid | ||
PRINTF("[-] Unknown authority received in value %d\n", output.value); | ||
explicit_bzero(&G_context, sizeof(G_context)); |
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.
Should we clear globals here?
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 clearing the global context.
The G_token_symbols
can be cleared but it is not a security issue to leave them initialized since only user confirmed tokens enter the G_token_symbols
context.
// set g_authority | ||
strlcpy(g_authority, symbol, MAX_TOKEN_SYMBOL_LEN + 1); | ||
g_authority[symbol_len] = ' '; | ||
if (is_mint_authority(output.token_data, output.value)) { |
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.
Aren't you showing what action is being performed? I mean, you can have a mint authority with the following actions: (i) minting, (ii) destroying, and (iii) delegating.
UX_STEP_NOCB(ux_display_authority_step, | ||
bnnn_paging, | ||
{ | ||
.title = "Authority", |
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.
Do we have room for "Token Authority"? Or is it too big?
Acceptance criteria