Skeleton issue

[dj8yfo]

Various

• chore: add safe_load.sh #2

Existing functionality

• congruent behaviour on INS_GET_PUBLIC_KEY and INS_GET_WALLET_ID - feat: display p1 flag in INS_GET_PUBLIC_KEY, add INS_GET_WALLET_ID #4
• chore: refactor Action parsing to use deserialize_in_place #5 , assert_eq!(mem::size_of::<Transfer>, 16)
• assert_eq!(mem::size_of::<TransactionPrefix>, 224)
• question: should public_key, nonce, block_hash fields of transaction prefix be displayed as well
• feat: add parse CreateAccount action #6 , assert_eq!(mem::size_of::<CreateAccount>, 0)
• question: can AccountId be Secp256K1PublicKey representation as hex string 128 bytes long?
• feat: DeleteAccount action #7 , assert_eq!(mem::size_of::<DeleteAccount>, 76)
• feat: DeleteKey action #8, assert_eq!(mem::size_of::<DeleteKey>, 65)
• feat: impl Stake action #9, assert_eq!(mem::size_of::<Stake>, 88)
• feat: impl AddKey action #10, assert_eq!(mem::size_of::<AddKey>, 88), assert_eq!(mem::size_of::<FunctionCallPermission>, 328)
• chore: cleanup AddKey #11
• feat: impl DeployContract action #12, assert_eq!(mem::size_of::<DeployContract>, 56)
  • TODO: add print of contract Vec<u8> SHA256 in near-cli-rs
• feat: impl FunctionCall action #13, assert_eq!(mem::size_of::<FunctionCallCommon>, 88), assert_eq!(mem::size_of::<CappedString<200>>, 212)
• feat: stub Delegate action signing with error #14
• fix: FunctionCall with binary args crash #18
  • chore: update to newer sdk; fix flaky bin args FunctionCall (handler rewrite, buffers reduced) #20

advantages as compared to app-near

• unlimited size of transactions
• normal support of batch transactions, test, screenshots of 2/12 action , none of the details of actions are shown in app-near

comparison of details shown with app-near

• CreateAccountAction
  • no change
• DeleteAccountAction
  • cargo run --example sign_delete_account_{short,long}
    • Beneficiary ID action field not displayed in app-near
• DeleteKeyAction
  • cargo run --example sign_delete_key_{ed25519/secp256k1}
    • Public Key action field not displayed in app-near
• StakeAction
  • cargo run --example sign_stake
    • Stake and Public Key fields of action not displayed in app-near
• TransferAction
  • cargo run --example sign_transfer
    • no change
• AddKeyAction
  • cargo run --example sign_add_key_fullaccess
    • Public Key field and access_key.Nonce field of action is not displayed in app-near
  • cargo run --example sign_add_key_functioncall
    • app-near displays this case identical to Full Access one (Public Key field and access_key.Nonce field of action is not displayed, no details show on Function Call Permission)
• DeployContractAction
  • cargo run --example sign_deploy_contract
    • code field of action not displayed in app-near; sha256 of code field is displayed in app-near-rs
• FunctionCallAction
  • gas field of action isn't displayed in app-near (string args argument)
  • gas field of action isn't diplayed, binary args argument displayed as blank in app-near

New functionality

• feat: implement nep-413 sign message flow #15
• feat: impl NEP-366 delegate action sign flow  #16
• feat: validate public key in sign_tx and sign_nep366_delegate_action flows #19
  • feat: improve display pub key validation #21

nep-413 message protocol

The protocol is similar to regular transaction signing, which has 20 bytes of 5-component BIP32Path followed by borsh serialization of transaction transferred over multiple apdu messages. There're two differences:

1. instruction byte in all of apdu headers is changed from 2 -> 7

const INS_SIGN_TRANSACTION: u8 = 2; // Instruction code to sign a transaction on the Ledger
const INS_SIGN_NEP413_MESSAGE: u8 = 7; // Instruction code to sign a nep-413 message with Ledger

2. 20 bytes of 5-component BIP32Path are followed by borsh serialization of NEP413Payload:

pub struct NEP413Payload {
    pub messsage: String,
    pub nonce: [u8; 32],
    pub recipient: String,
    pub callback_url: Option<String>,
}

Sample code which forms and sends such a message is targeted by this link.

nep-366 message protocol

The protocol is similar to regular transaction signing, which has 20 bytes of 5-component BIP32Path followed by borsh serialization of transaction transferred over multiple apdu messages. There're two differences:

1. instruction byte in all of apdu headers is changed from 2 -> 8

const INS_SIGN_TRANSACTION: u8 = 2; // Instruction code to sign a transaction on the Ledger
const INS_SIGN_NEP366_DELEGATE_ACTION: u8 = 8; // Instruction code to sign a nep-366 delegate action with Ledger

2. 20 bytes of 5-component BIP32Path are followed by borsh serialization of DelegateAction:

pub struct DelegateAction {
    /// Signer of the delegated actions
    pub sender_id: AccountId,
    /// Receiver of the delegated actions.
    pub receiver_id: AccountId,
    /// List of actions to be executed.
    ///
    /// With the meta transactions MVP defined in NEP-366, nested
    /// DelegateActions are not allowed. A separate type is used to enforce it.
    pub actions: Vec<NonDelegateAction>,
    /// Nonce to ensure that the same delegate action is not sent twice by a
    /// relayer and should match for given account's `public_key`.
    /// After this action is processed it will increment.
    pub nonce: Nonce,
    /// The maximal height of the block in the blockchain below which the given DelegateAction is valid.
    pub max_block_height: BlockHeight,
    /// Public key used to sign this delegated action.
    pub public_key: PublicKey,
}
pub type Nonce = u64;
pub type BlockHeight = u64;

Sample code which forms and sends such a message is targeted by this link.

CI/Ragger tests

details

• ci: fix spelling + clippy #22
• test: Ragger tests skeleton + initial test_get_version_cmd #23
• test: test_get_public_key_and_confirm_screen added #24
• test: add test_sign_transfer #26
• test: add test_sign_create_account #27
• test: add test_delete_account #28
• test: add test_sign_delete_key #29
• test: add test_sign_stake #30
• test: add test_sign_add_key #31
• test: add test_sign_deploy_contract #32
• test: add test_sign_function_call #33
• test: add test_batch_all_actions #34
• test: add test_sign_nep413_msg #37
• test: add test_sign_nep366_delegate_action #38
• test: add test_public_key_validation #39
• chore: format *.py tests #40

Encountered issues:

• using ledger-app-builder:latest with rustc 1.75.0-nightly (0f44eb32f 2023-11-09) crashes a nanos app  LedgerHQ/ledger-device-rust-sdk#122
• non-ASCII chars aren't supported by SDK: as indicated by rework MultiFieldReview to use less stack LedgerHQ/ledger-device-rust-sdk#120 (comment), attempting to work with non-ASCII strings will undeterministically result in either app crashes or displaying blanks instead of parts of strings. Suggestion was made to declare explicit support of ASCII-only in Suggestion: declare explicit support of ASCII-only charset at SDK level LedgerHQ/ledger-device-rust-sdk#124.
  • non-ASCII chars not supported by C sdk as well
  • SDK works with newlines present in msgs, but appears to be skipping small chunks of msgs, when newlines are present
    • this was formally described by issue newline \n and carriage return \r problems with MultiFieldReview<'a> LedgerHQ/ledger-device-rust-sdk#146

These LedgerHQ/ledger-device-rust-sdk#124 and LedgerHQ/ledger-device-rust-sdk#146 haven't been resolved yet, but have been worked around by #47

[frol]

question: should public_key, nonce, block_hash fields of transaction prefix be displayed as well

Nah, it is useless for users. Public key has to match the private key on Ledger, so you may validate this and it would be better than asking user to do that.

question: can AccountId be Secp256K1PublicKey representation as hex string 128 bytes long?

Nope, but before you asked, I have never really put a thought that NEAR doesn't support implicit accounts with keys different than ed25519. Which is a bit odd, but it makes things simpler

[dj8yfo]

mentioned in README