Feature/ledger signer

[OBorce]

• 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?

[ImplOfAnImpl]

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.

[OBorce]

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.

[ImplOfAnImpl]

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.

[ImplOfAnImpl]

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.