Add Eos support

[atkachyshyn]

No description provided.

[matejcik]

did you just re-submit PR #197 ? if not, what are the differences?

[atkachyshyn]

Yes, it's evolved resubmit, just from different account. ср, 7 лист. 2018 о 14:45 matejcik <notifications@github.com> пише:

…

did you just re-submit PR #197 <#197> ? if not, what are the differences? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#231 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGzlc4ncyesrrYN56mhZ9cO_4gd5Hjxlks5ustX-gaJpZM4YRBUO> .

[matejcik]

@atkachyshyn please close one of the PRs then, if you control both

Also please remove the "unknown action" field, this should not be supported per #197 (comment)

[tarassh]

@matejcik Unknown action is kind of equivalent for tx payload in etc https://github.com/trezor/trezor-common/blob/master/protob/messages-ethereum.proto#L67

In order to control Eos account: manage permissions, transfer funds, buy/sell/delegate system resources, actions mentioned in PR were implemented, those are part of contracts that are called system contracts.

As for Unknown, this type of action should work for any dApps smart contracts developed by users/community.

Like payload in ETH, Unknown should do the same, but with an advantage. We are able to display smart contract name, and smart contract method, which should be executed. User warned with message for arbitrary data and arguments are presented as sha256 checksum.

[atkachyshyn]

Hi @matejcik Thank's for suggestions and pointing out some misspellings. Do you have any updates or probably some further suggestions? Looking forward to hearing from you

[matejcik]

I still dislike the unknown actions.

@keepkeyjon you seem to understand this better. What is stopping me from passing raw transaction bytes (say, "send many assets to my account") as EosActionUnknown message? Does the signature include action type?

[keepkeyjon]

Does the signature include action type?

yes, this is committed to in each action's hash. see:
https://github.com/keepkey/keepkey-firmware/blob/8b4e608a14b06b93608a4e60bf82b2e29f790c26/lib/firmware/eos-contracts/eosio.token.c#L94
https://github.com/keepkey/keepkey-firmware/blob/8b4e608a14b06b93608a4e60bf82b2e29f790c26/lib/firmware/eos.c#L294

If the implementation of the hasher for ActionUnknown checks for "known" actions as I've done here, then an attacker won't be able to use an unknown action to trick a user into transferring assets, since they won't be able to use the transfer action on the token contract without going through the flow that shows what's actually happening.

I personally don't love ActionUnknown either, which is why I've stuck it behind an opt-in chicken bit. Maybe it makes sense to do the same thing on Trezor (through ApplySettings?)

[matejcik]

alright, thanks for the info

merged via e1d1526