Support Trezor 1.3.3 (breaking change) about multibit-hardware

[slush0]

Hi Jim, PIN challenges are hardcoded to workflows? If they're implemented
properly - as event handlers for PinMatrixRequest, no change in client
codebase is required.

Best,
Marek

On Wed, Apr 1, 2015 at 11:32 AM, Jim Burton [email protected]
wrote:

There is a breaking change in Trezor 1.3.3 firmware - GetPublicKey now
issues a PIN challenge

Reply to this email directly or view it on GitHub
#15.

[gary-rowe]

We use event handlers, we just don't expect all events in all workflows.

This translates up the stack into MBHD where wizard screens progress based on expected events rather than randomly skip around due to unexpected messages being pushed from the device.

[slush0]

I see. However, it should be pretty straightforward to change event handler to expect PIN and/or passphrase (well, you don't support passphrases yet, but the logic is the same) messages for virtually any message.

Also, Trezor uses caching mechanism for PIN and passphrase, so not every "PIN protected" message will trigger PinRequest on every call.

[gary-rowe]

Yes, it's a breaking change for us but not a difficult one. The ConfirmGetPublicKey simply needs support for PIN added.

This then bubbles up to MBHD to trigger the PIN handling in the FSM backing the credentials wizard.

[jim618]

As Gary states, it's not a big issue.
There will most likely be a gap in time from when Trezor 1.3.3 comes out and when we release MBHD Beta 8 (as we have other stuff to get in) but it should not be problematic.

[gary-rowe]

Verified working.

Closing.