Feature/ledger signer #1944

OBorce · 2025-07-30T13:35:25Z

Ledger signer
Ledger tests

Tests assume the ledger app is already running in the emulator same as Trezor tests

ImplOfAnImpl

I haven't dug into the code much yet, will continue next week.

Tests assume the ledger app repo is cloned next to this one with name ledger-mintlayer

To be honest, I'm not a huge fan of this approach. And also of the fact that the emulator is always started automatically. E.g. in the Trezor case it was sometimes useful to see the emulator logs to understand what went wrong.
Was there any particular reason to do it this way instead of expecting the emuator to be running?

wallet/src/signer/ledger_signer/speculus/drivers/mod.rs

wallet/src/signer/ledger_signer/speculus/handle.rs

Cargo.toml

wallet/src/signer/ledger_signer/speculus/mod.rs

wallet/src/signer/ledger_signer/speculos/handle.rs

wallet/src/signer/ledger_signer/speculos/drivers/mod.rs

wallet/src/signer/ledger_signer/ledger_messages.rs

Cargo.toml

wallet/src/signer/ledger_signer/ledger_messages.rs

ImplOfAnImpl · 2025-10-08T12:25:48Z

wallet/src/signer/ledger_signer/ledger_messages.rs

+pub async fn get_app_name<L: Exchange>(ledger: &mut L) -> Result<Vec<u8>, ledger_lib::Error> {
+    let msg_buf = [CLA, Ins::APP_NAME, 0, P2::DONE];
+    ledger.exchange(&msg_buf, Duration::from_millis(100)).await
+}
+
+#[allow(dead_code)]
+pub async fn check_current_app<L: Exchange>(ledger: &mut L) -> SignerResult<()> {
+    let resp = get_app_name(ledger)
+        .await
+        .map_err(|err| LedgerError::DeviceError(err.to_string()))?;


I don't think it's a good way to check for our app, because the INS values are app-specific.

There is a standard way to obtain the app name via CLA=0xB0 and INS=1. E.g. here it's handled by the SDK on the device - https://github.com/LedgerHQ/ledger-device-rust-sdk/blob/4262899a325b9b2fe10f2524d8e4b2f9fec38b83/ledger_device_sdk/src/io_legacy.rs#L330-L331
(The INS is processed inside the handle_bolos_apdu function).

Also, ledger-proto contains something called AppInfoReq which mentions CLA 0xB0 and INS 1, so I guess you don't have to construct the APDU by hand and parse the request.

For some reason it always returns "app" for app name and the OS version instead of the opened app. So, I kept our own instructions.

For some reason it always returns "app" for app name and the OS version instead of the opened app. So, I kept our own instructions.

Well, I tried sending [b0, 1, 0, 0] to my NanoSPlus and got "Mintlayer"/"0.1.0" for our app and "Ethereum"/"1.18.0" for Ethereum.
What device are you using? Can you double check?

In any case, this has to be investigated further. If b0/01 doesn't work indeed, we must at least document that fact, mentioning the particular situations.

For some reason it always returns "app"

So I suppose you were using the emulator, for which this is documented behavior.

In such a case IMO it's better to detect if we're using an emulator (or I guess we could assume that any tcp transport corresponds to an emulator) and skip the app name/version check in that case.

Alternatively, we could go with with a custom APDU. But in this case it has to be handled more carefully. E.g. a) expect that the whole APDU may fail, e.g. with ClaNotSupported or InsNotSupported (because the current app doesn't support it), or with something like WrongP1P2/WrongApduLength (because in the current app this APDU means something else and has different parameters); b) expect that APDU may be handled successfully, but the result is garbage (again, because in the current app this APDU means something else).

The first approach looks easier to implement.

wallet/src/signer/ledger_signer/mod.rs

wallet/src/signer/ledger_signer/tests.rs

ImplOfAnImpl · 2025-10-30T12:44:29Z

wallet/src/signer/ledger_signer/mod.rs

+                Err(ledger_lib::Error::Timeout) => {
+                    continue;
+                }


I don't think it's a good idea to ignore timeouts indefinitely. Perhaps we should only allow a few timeouts and then fail?
But why do we even need to handle a timeout differently that other connection errors that a re handled below?

wallet/src/signer/ledger_signer/mod.rs

wallet/src/signer/ledger_signer/ledger_messages.rs

ImplOfAnImpl · 2025-10-30T17:01:29Z

wallet/src/signer/ledger_signer/mod.rs

+        .await
+        .map_err(|err| LedgerError::DeviceError(err.to_string()))?;
+
+    let device = devices.pop().ok_or(LedgerError::NoDeviceFound)?;


On my Linux machine I get the following here:

devices: [LedgerInfo { model: NanoSPlus, conn: Usb(UsbInfo { vid: 11415, pid: 20480, path: Some("3-2:1.0") }) }, LedgerInfo { model: NanoSPlus, conn: Usb(UsbInfo { vid: 11415, pid: 20480, path: Some("3-2:1.1") }) }]

They are 2 separate HID interfaces to the same actual device, one of them is the APDU interface and another - the FIDO/U2F one (according to ChatGPT).
In my case your code selects the non-APDU interface and I get empty responses from it.

So,

What are you getting on Windows here? Also, what device(s) are you using?

Relying on a particular interface having a particular index in the returned vector won't work in general. According to ChatGPT, we should prefer the one with interface_number == 0, but rust-ledger doesn't expose interface_number. I.e. this needs further investigation after which we should either make a PR to rust-ledger with the corresponding improvement or fork it.

I've reported this and some other issues to rust-ledger here, but it's likely that we'll have to fix them ourselves. Though I'm still not sure whether we should submit a PR or just fork the repo.

ImplOfAnImpl · 2025-10-30T19:34:16Z

wallet/src/signer/ledger_signer/ledger_messages.rs

+pub async fn get_app_name<L: Exchange>(ledger: &mut L) -> Result<Vec<u8>, ledger_lib::Error> {
+    let msg_buf = [CLA, Ins::APP_NAME, 0, P2::DONE];
+    ledger.exchange(&msg_buf, Duration::from_millis(100)).await
+}
+
+#[allow(dead_code)]
+pub async fn check_current_app<L: Exchange>(ledger: &mut L) -> SignerResult<()> {
+    let resp = get_app_name(ledger)
+        .await
+        .map_err(|err| LedgerError::DeviceError(err.to_string()))?;


For some reason it always returns "app" for app name and the OS version instead of the opened app. So, I kept our own instructions.

Well, I tried sending [b0, 1, 0, 0] to my NanoSPlus and got "Mintlayer"/"0.1.0" for our app and "Ethereum"/"1.18.0" for Ethereum.
What device are you using? Can you double check?

In any case, this has to be investigated further. If b0/01 doesn't work indeed, we must at least document that fact, mentioning the particular situations.

node-gui/src/main_window/main_menu.rs

ImplOfAnImpl · 2025-11-05T10:29:27Z

node-gui/src/main_window/main_widget/tabs/wallet/status_bar.rs

            ]
        }
+        #[cfg(feature = "ledger")]
+        WalletExtraInfo::LedgerWallet { app_version } => {


Comment from PR #1946:

IMO we should be able to obtain the device name for the ledger too (which will be the model name, not the label set in Ledger Live, but it's still better than nothing).

As I've mentioned in the ledger app PR, it seems like the APDU 0xE0/0x01 is "get device info" (need to check if it works when an app is opened though). One of the returned values is targetId, from which the model name can be deduced.

Ledger Live sometimes calls this endpoint - https://manager.api.live.ledger.com/api/devices - to get the device model name (by comparing obtained the device's targetId with target_id inside device_versions of the returned json.)
(I'm not suggesting to use their endpoint, but we might just take its current values and hardcode them).

And it also has a hardcoded array of device infos and this function obtains them by targetId - https://github.com/LedgerHQ/ledger-live/blob/2dddf3a308ec6bd9fa436c7bc5bc02bcb33593e6/libs/ledgerjs/packages/devices/src/index.ts#L176-L182

ImplOfAnImpl · 2025-11-05T18:45:22Z

wallet/src/signer/ledger_signer/mod.rs

+        .await
+        .map_err(|err| LedgerError::DeviceError(err.to_string()))?;
+
+    let device = devices.pop().ok_or(LedgerError::NoDeviceFound)?;


I've reported this and some other issues to rust-ledger here, but it's likely that we'll have to fix them ourselves. Though I'm still not sure whether we should submit a PR or just fork the repo.

ImplOfAnImpl · 2025-11-05T19:25:39Z

wallet/src/signer/ledger_signer/ledger_messages.rs

+pub async fn get_app_name<L: Exchange>(ledger: &mut L) -> Result<Vec<u8>, ledger_lib::Error> {
+    let msg_buf = [CLA, Ins::APP_NAME, 0, P2::DONE];
+    ledger.exchange(&msg_buf, Duration::from_millis(100)).await
+}
+
+#[allow(dead_code)]
+pub async fn check_current_app<L: Exchange>(ledger: &mut L) -> SignerResult<()> {
+    let resp = get_app_name(ledger)
+        .await
+        .map_err(|err| LedgerError::DeviceError(err.to_string()))?;


For some reason it always returns "app"

So I suppose you were using the emulator, for which this is documented behavior.

In such a case IMO it's better to detect if we're using an emulator (or I guess we could assume that any tcp transport corresponds to an emulator) and skip the app name/version check in that case.

Alternatively, we could go with with a custom APDU. But in this case it has to be handled more carefully. E.g. a) expect that the whole APDU may fail, e.g. with ClaNotSupported or InsNotSupported (because the current app doesn't support it), or with something like WrongP1P2/WrongApduLength (because in the current app this APDU means something else and has different parameters); b) expect that APDU may be handled successfully, but the result is garbage (again, because in the current app this APDU means something else).

The first approach looks easier to implement.

wallet/src/signer/ledger_signer/ledger_messages.rs

ImplOfAnImpl · 2025-11-06T09:26:18Z

.github/workflows/build.yml

+          sudo docker run --rm \
+            -v "$(realpath ./mintlayer-ledger-app):/app" \
+            ghcr.io/ledgerhq/ledger-app-builder/ledger-app-dev-tools:latest \
+            sh -c 'cd /app && cargo ledger build nanosplus'


Need to run the tests for all possible models.

(This is the whole reason of having run_tests_on_trezor_preparation as a separate job - so that the tests are not built over and over again.)

To run a job multiple times with different parameters you use strategy.matrix - the job will be run once for each combination of variables inside it. E.g. in run_tests_on_trezor there is one variable called model, which is then referenced as ${{ matrix.model }} inside the job's body.

Something similar should be done for Ledger.

.github/workflows/build.yml

node-gui/backend/src/error.rs

wallet/src/signer/ledger_signer/speculos/handle.rs

wallet/src/signer/ledger_signer/speculos/mod.rs

wallet/src/signer/ledger_signer/tests.rs

ImplOfAnImpl · 2025-11-06T13:54:48Z

wallet/src/signer/ledger_signer/tests.rs

+    Finish,
+}
+
+async fn auto_confirmer(mut control_msg_rx: mpsc::Receiver<ControlMessage>, handle: PodmanHandle) {


Let's have a way to disable the auto-confirmer, to be able to see what the tests are really doing. E.g. for trezor we have the TREZOR_TESTS_AUTO_CONFIRM env var, so we can also have LEDGER_TESTS_AUTO_CONFIRM.

If you disable auto-confirmation (I did it by commenting out the "handle.button" calls below), you'll notice that when running e.g. test_fixed_signatures2::case_1, you have to click the right button 19 times while the device is showing "Review transaction" without any indication that something is happening. I guess it's when the transaction data is being sent in chunks. But in any case, just sending data shouldn't require the user to perform clicks, clicking should only be needed to go to another screen.,

At some point during signing, a message is shown "Press right button to continue message or press both to skip". If both buttons are pressed, it goes straight to "Sign transaction", if the right one is pressed, it also shows a few extra screens related to fees. So:
a) Is this something our app controls? If so, IMO it's better to disable it and always show all the screens.
b) Otherwise we're testing only one of the possible successful flows, which is not great. I guess in such a case we shouldn't just click arbitrary and instead have a list of button clicks that must be performed for each test and also a way to check what is currently shown on the screen (e.g. in the simplest case it could be a list of pairs ("regex that checks the expected contents of the current screen", "button click to go to the next screen")). Though this approach seems to be the correct one, as it'll also allow us to have negative tests, where the operation is aborted by the user (and ideally we should do the same for Trezor tests), it'll probably be hard to implement, so I'd go with the option a) for now, if possible.

wallet/src/signer/ledger_signer/mod.rs

wallet/src/signer/ledger_signer/ledger_messages.rs

ImplOfAnImpl · 2025-11-07T09:38:31Z

wallet/src/signer/ledger_signer/ledger_messages.rs

+        msg_buf.extend([APDU_CLASS, ins, p1, p2]);
+        msg_buf.push(chunk.len() as u8);
+        msg_buf.extend(chunk);
+        resp = exchange_message(ledger, &msg_buf).await?;


Again, let's not ignore intermediate results. If they are supposed to be empty vecs, let's do sanity checks on that.

wallet/src/signer/ledger_signer/ledger_messages.rs

ImplOfAnImpl

Seems to be fine (except for a few comments), but I'd like to take another look after I return from my vacation.

ImplOfAnImpl · 2025-12-19T12:54:37Z

wallet/src/signer/ledger_signer/mod.rs

+        // Ledger support is released
+        ensure!(
+            input_commitment_version == common::chain::SighashInputCommitmentVersion::V1,
+            LedgerError::MultisigSignatureReturned


Wrong error

ImplOfAnImpl · 2025-12-19T12:56:17Z

wallet/src/signer/ledger_signer/mod.rs

+        key_chain: &impl AccountKeyChains,
+    ) -> SignerResult<()> {
+        let mut client = self.client.lock().await;
+        // Try and wait around 5sec 50 * 100ms for the screen to clear after a signing operation ends


"5sec 50 * 100ms" - I guess the "5sec" part is redundant

ImplOfAnImpl · 2025-12-19T14:22:30Z

.github/workflows/build.yml

+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout the core repository
+        uses: actions/checkout@v4


In other places we now use actions/checkout@v5, use it here too for consistency.
Same below

ImplOfAnImpl · 2025-12-19T14:25:48Z

.github/workflows/build.yml

+        uses: actions/checkout@v4
+        with:
+          repository: mintlayer/mintlayer-ledger-app
+          ref: feature/mintlayer-app


Plz don't forget to update this

ImplOfAnImpl · 2025-12-19T14:27:34Z

.github/workflows/build.yml

+          path: ./mintlayer-core
+      - name: Update local dependency repositories


Plz separate steps from each other with empty lines, it's much easier to read them this way.
Same below

ImplOfAnImpl · 2025-12-19T15:44:42Z

wallet/src/signer/ledger_signer/speculos.rs

+    /// Returns true if the device has a touch screen
+    pub fn is_touch(&self) -> bool {
+        matches!(self, Device::Stax | Device::Flex)
+    }


NanoGen5 also has it

ImplOfAnImpl · 2025-12-19T15:46:40Z

wallet/src/signer/ledger_signer/speculos.rs

@@ -0,0 +1,233 @@
+// Copyright (c) 2025 RBB S.r.l


lets create a separate folder "tests" and put both speculos.rs and the tests there

ImplOfAnImpl · 2025-12-19T15:47:46Z

wallet/src/signer/ledger_signer/speculos.rs

+    /// Send a physical button action
+    pub async fn button(&self, button: Button, action: ButtonAction) -> anyhow::Result<()> {
+        if self.device.is_touch() {
+            log::warn!("Sending physical button command to a touch device (Stax/Flex). This might be intended (Power button) but usually incorrect for UI navigation.");


Overly long string literals often break rustfmt. Plz split this one, e.g. via concat!

ImplOfAnImpl · 2025-12-19T15:58:31Z

wallet/src/signer/ledger_signer/ledger_messages.rs

+        chain::output_value::OutputValue::Coin(amount) => {
+            LOutputValue::Coin(to_ledger_amount(amount))
+        }
+        chain::output_value::OutputValue::TokenV0(_) => panic!("unsupported V0"),


Let's not panic and return an error instead (e.g. UnsupportedTokenV0)

ImplOfAnImpl · 2025-12-19T16:04:21Z

wallet/src/signer/ledger_signer/ledger_messages.rs

+pub fn to_ledger_tx_output(value: &chain::TxOutput) -> LTxOutput {
+    ledger_decode_all(value.encode().as_slice()).expect("ok")
+}
+
+pub fn to_ledger_amount(value: &primitives::Amount) -> LAmount {
+    LAmount::from_atoms(value.into_atoms())
+}
+
+pub fn to_ledger_outpoint(value: &chain::UtxoOutPoint) -> LUtxoOutPoint {
+    ledger_decode_all(value.encode().as_slice()).expect("ok")
+}
+
+pub fn to_ledger_account_outpoint(value: &chain::AccountOutPoint) -> LAccountOutPoint {
+    ledger_decode_all(value.encode().as_slice()).expect("ok")
+}
+
+pub fn to_ledger_account_nonce(value: &chain::AccountNonce) -> LAccountNonce {
+    ledger_decode_all(value.encode().as_slice()).expect("ok")
+}
+
+pub fn to_ledger_account_command(value: &chain::AccountCommand) -> LAccountCommand {
+    ledger_decode_all(value.encode().as_slice()).expect("ok")
+}
+
+pub fn to_ledger_order_account_command(value: &chain::OrderAccountCommand) -> LOrderAccountCommand {
+    ledger_decode_all(value.encode().as_slice()).expect("ok")
+}


This is not great. Perhaps we should move the code from common/tests/primitives_repo_consistency/utils/converters.rs from tests to the common crate itself and use it here.
But note that we'll need to get rid of the panic for TokenV0 inside the converters and return an error instead. Which means that ConvertFrom/convert_from should become TryConvertFrom/try_convert_from and return a Result. The error type for the result should IMO be a separate type containing only one error variant (UnsupportedTokenV0).

Also, the "L" aliases for the primitives repo types are not needed IMO (or at least they should be "P", because they are specific not to the Ledger, but to the primitives repo).

OBorce changed the base branch from master to refactor/wallet-async-signing July 30, 2025 13:35

OBorce force-pushed the feature/ledger_signer branch 2 times, most recently from ecf51c0 to abe8a88 Compare July 31, 2025 08:24

OBorce force-pushed the refactor/wallet-async-signing branch from 59bd742 to 9099e90 Compare August 22, 2025 10:57

OBorce force-pushed the feature/ledger_signer branch from abe8a88 to 89285d1 Compare August 22, 2025 10:58

OBorce marked this pull request as ready for review August 25, 2025 12:43

OBorce requested review from ImplOfAnImpl and erubboli as code owners August 25, 2025 12:43

OBorce force-pushed the feature/ledger_signer branch from 5f20a4f to 4c64407 Compare August 25, 2025 12:56

ImplOfAnImpl reviewed Aug 28, 2025

View reviewed changes

OBorce force-pushed the refactor/wallet-async-signing branch 3 times, most recently from f21e82b to 75ff652 Compare September 18, 2025 22:31

OBorce force-pushed the feature/ledger_signer branch 4 times, most recently from 61292c5 to eeb6484 Compare September 23, 2025 22:28

OBorce marked this pull request as draft September 25, 2025 08:51

OBorce force-pushed the refactor/wallet-async-signing branch from 75ff652 to 96016cf Compare September 25, 2025 08:57

OBorce force-pushed the feature/ledger_signer branch 3 times, most recently from 5d3edf0 to d6fd484 Compare September 30, 2025 23:37

OBorce marked this pull request as ready for review October 1, 2025 07:09

OBorce force-pushed the feature/ledger_signer branch from 39d3e58 to d6fd484 Compare October 3, 2025 07:07

ImplOfAnImpl requested changes Oct 8, 2025

View reviewed changes

ImplOfAnImpl reviewed Oct 9, 2025

View reviewed changes

wallet/src/signer/ledger_signer/mod.rs Outdated Show resolved Hide resolved

ImplOfAnImpl reviewed Oct 9, 2025

View reviewed changes

wallet/src/signer/ledger_signer/mod.rs Outdated Show resolved Hide resolved

ImplOfAnImpl reviewed Oct 9, 2025

View reviewed changes

wallet/src/signer/ledger_signer/tests.rs Outdated Show resolved Hide resolved

OBorce force-pushed the feature/ledger_signer branch from d6fd484 to 2d5300b Compare October 26, 2025 23:34

OBorce changed the base branch from refactor/wallet-async-signing to master October 26, 2025 23:39

OBorce force-pushed the feature/ledger_signer branch 2 times, most recently from fbbfd75 to 1ae1ecc Compare October 28, 2025 09:03

ImplOfAnImpl reviewed Oct 30, 2025

View reviewed changes

ImplOfAnImpl reviewed Nov 6, 2025

View reviewed changes

ImplOfAnImpl requested changes Nov 7, 2025

View reviewed changes

OBorce force-pushed the feature/ledger_signer branch 2 times, most recently from 4f56961 to 132141f Compare November 13, 2025 19:47

OBorce added 12 commits December 19, 2025 12:26

Add ledger signer

b16c473

fix ledger tests

85fa4c9

ledger cleanup

a27d88d

Remove podman usage from Ledger tests, fix comments

8ae3563

Use the new ledger messages

de666de

Add Ledger signer provider

0583127

Add ledger support in CLI and GUI wallet

dcb9a3b

Add ledger CI tests

9b5c7f7

fix comments

002d224

Fix comments

21bb4c3

Add support for Flex and Stax Ledger emulator tests

1a33b70

Use new ledger messages

a7d86d1

OBorce force-pushed the feature/ledger_signer branch from 50d5293 to a7d86d1 Compare December 19, 2025 12:31

ImplOfAnImpl reviewed Dec 19, 2025

View reviewed changes

		path: ./mintlayer-core
		- name: Update local dependency repositories

Feature/ledger signer #1944

Are you sure you want to change the base?

Feature/ledger signer #1944

Uh oh!

Conversation

OBorce commented Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ImplOfAnImpl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ImplOfAnImpl left a comment

Choose a reason for hiding this comment

OBorce commented Jul 30, 2025 •

edited

Loading