eth_signTypedData on Trezor account fails without callback

[rudolfix]

When sending eth_signTypedData to web3 provider injected by metamask when Trezor account is active, callback (after clicking SIGN in ui) is not called and the console logs Not supported on this device.

to reproduce

1. add and select Trezor account
2. send properly formatted eth_signTypedData to the web3.currentProvider
3. Click SIGN in the signature ui

expected behavior

1. callback is being called in case of error
2. you are able to sign Ethereum message with Trezor

browse:

• Chrome 68.0.3440.84/Windows
• Metamask 4.9.2

This bug prevents users from logging in to services that use Ethereum wallets to login users. error message looks like Trezor does not support signing Messages, is this the case?

[bdresser]

@rudolfix Trezor doesn't currently support eth_signTypedData: trezor/trezor-core#122

Since EIP 712 has been finalized, hopefully they'll begin to support it soon.

[rudolfix]

@bdresser thanks! what about eth_sign? I think that it is deprecated in Metamask so there is no way to use it, correct? do you known if any signature scheme works for Metamask + Trezor combination?

On the other note, calling a callback in case of error would be really helpful.

[bdresser]

Try personal_sign!

[rudolfix]

is there a way to detect we have trezor attached? I do not want to drop eth_signTypedData for regular accounts. anyway, thanks! we'll surely try personal_sign just to see if it works

[bdresser]

no, we don't expose whether the user is signing with a Trezor or a standard MetaMask account.

Since EIP 712 is merged, Trezor may hopefully support signTypedData shortly. Try commenting on the issue referenced above to let them know you're looking forward to this feature!

[EagleTM]

I can login fine to https://app.ledgerdex.com/ with signatures using Trezor with fw 1.7.1 and Metamask 5.3.0 on Chrome. Could this mean this problem is gone or which sig function is used by ledgerdex?

[danfinlay]

I have a new proposal for how we may be able to address this issue in the future:

Rather than allowing sites to detect the account type a user has, it could specify before connecting what features it requires during the session:

#6994