You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
current implementation of container reader does not check resulting container against requested ID which is essentially its checksum. Thus, malicious/buggy server can return a correct but different container, and the app is unlikely to double-check it. This can lead to unexpected or even fatal consequences
choosing b/w alternatives:
leave behavior as it is, add a warning to the docs
make client to always check
make client to check and add option to skip the check
i prefer 2 cuz, with the possible exception of testing, verified information is always expected. The need to receive information from the server “as is” may arise, but such specifics fit better into the option (i.e. implement 3, but when it'll really needed)
P.S. the same needs to be done for objects
The text was updated successfully, but these errors were encountered:
On one hand, self-checking OID/CID is a powerful thing, you can know you've got the right thing. But on the other consider blockchain interactions --- RPC node can technically return us any kind of data about balance, height, notifications, state. The only thing you can really check is blocks. And transactions included there. But what you really are interested in is state and you can only trust the node to return it to you correctly unless you have some kind of MPT verification.
One thing I'm thinking about is having better in-contract structures for containers. So that they'd be independent of protobuf serialization and potentially could even be changed. This would break this check immediately. But it'd be a powerful thing at the same time.
current implementation of container reader does not check resulting container against requested ID which is essentially its checksum. Thus, malicious/buggy server can return a correct but different container, and the app is unlikely to double-check it. This can lead to unexpected or even fatal consequences
choosing b/w alternatives:
i prefer 2 cuz, with the possible exception of testing, verified information is always expected. The need to receive information from the server “as is” may arise, but such specifics fit better into the option (i.e. implement 3, but when it'll really needed)
P.S. the same needs to be done for objects
The text was updated successfully, but these errors were encountered: