Sub Msg Response data when over-ridden and padded returns with trailing spaces
xucito opened this issue · comments
When a sub msg is responded to via another reply_on and padded, it looks like the padding is adding trailing spaces on text
Example Process
1. Sub Msg (Contract A)
2. Sub Msg (Contract B)
3. Response (Contract C)
4. Reply_on (Contract B) set data to be env.contract.addr
5. Reply_on (Contract A) receives the data with trailing spaces
To replicate:
https://github.com/securesecrets/shadeswap/tree/80c334d6bbf2ded38259fa72b4e2e2bbc15126b0
To run the test
server start
on another terminal
server-connect
make && make integration-tests
In contracts/factory/src/contract.rs the contract_address has unexpected trailing spaces (we are currently replacing " " with "" to handle the trailing spaces)
contracts/amm_pair/src/contract.rs you can see the way we pad response and return address
Tested with https://github.com/scrtlabs/LocalSecret/pkgs/container/localsecret/48072123?tag=beta-nested-attributes
@xucito Thank you for reporting the issue, I'll look into it an let you know as soon as I will have any verdict
Just to clarify, we are padding the spaces there to obscure the msg length to prevent guessing of content
The issue is more a question of whether
a) There is another way we should be padding so we don't have this issue
b) On Secret Network, the practice should be we have to assume that responses can always be padded with spaces specifically so we always need to remove trailing " "
It's a matter of you deciding the API between your contracts. If you know that the callee pads its responses then the caller should strip the padding from the response.
An example is sub-msgs against SNIP20 tokens would be common use-case to standardize against. I can see in the reference implementation for SNIP20 you have the same space padding so I will just use that assumptions.
This should be the standard for the network to prevent future conflicts I guess.
You're right, this can be improved and abstracted away from devs & users. Thanks for the feedback!
Just to clarify, we are padding the spaces there to obscure the msg length to prevent guessing of content
The issue is more a question of whether a) There is another way we should be padding so we don't have this issue b) On Secret Network, the practice should be we have to assume that responses can always be padded with spaces specifically so we always need to remove trailing " "
Sorry now I understand it better was sure that the padding was the issue in here, as @assafmo said, sounds like a good improvement we can make!