Closed atkachyshyn closed 5 years ago
Yes, it's evolved resubmit, just from different account.
ср, 7 лист. 2018 о 14:45 matejcik notifications@github.com пише:
did you just re-submit PR #197 https://github.com/trezor/trezor-common/pull/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 https://github.com/trezor/trezor-common/pull/231#issuecomment-436611388, or mute the thread https://github.com/notifications/unsubscribe-auth/AGzlc4ncyesrrYN56mhZ9cO_4gd5Hjxlks5ustX-gaJpZM4YRBUO .
@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 https://github.com/trezor/trezor-common/pull/197#issuecomment-416143356
@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.
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
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?
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
?)
alright, thanks for the info
merged via e1d15264534e4fe187aedc27372667f06ebf566c
did you just re-submit PR #197 ? if not, what are the differences?