Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

eosio.cdt writes to predictable and conflicting file in /tmp #742

Open
godmar opened this issue Nov 12, 2019 · 3 comments · Fixed by AntelopeIO/cdt#115 · May be fixed by #1070
Open

eosio.cdt writes to predictable and conflicting file in /tmp #742

godmar opened this issue Nov 12, 2019 · 3 comments · Fixed by AntelopeIO/cdt#115 · May be fixed by #1070
Assignees

Comments

@godmar
Copy link

godmar commented Nov 12, 2019

While debugging #741, I noticed that your eosio-cpp driver uses a temporary file in /tmp that's created ad-hoc by concatenating "/tmp" and the file name, e.g. /tmp/addressbook_with_age_and_notify.cpp.o when compiling addressbook_with_age_and_notify.cpp in a directory.

See here for the code that does this.

The above would make sense only in a single-user, single-process environment, otherwise it opens up the potential for conflicts or even TOCTOU attacks.

@larryk85
Copy link
Contributor

Thank you godmar, currently aware of this. Bigger changes that are in the works for eosio-cpp/cc will eliminate these concerns as they will remove the generation of these temporary files altogether.

@godmar
Copy link
Author

godmar commented Nov 13, 2019

Thanks, Bucky. May I ask a follow-up question. Smart contracts are published in C++ source code form, but only the WASM code is recorded in the blockchain, is that correct? If so, how do you ensure that the source code published matches the WASM code that's activated in the blockchain as compiler toolchains are being upgraded? Related, how can blockchain users verify easily which C++ code is actually running in the blockchain's VM?

@larryk85
Copy link
Contributor

larryk85 commented Dec 2, 2019

Currently, the best option users have is to use CMake to build their smart contracts. This would at least ensure that any options, defines, etc. are known for any one else to compile their smart contract. They would have to have the version of CDT that the contract was compiled with. From there they can get the hash of the code on chain and compare with their built contract. I am working on an extension to WASM (custom section) that would house some of this information. I am still trying to work out a reasonable solution to this and how to validate this when external libraries are linked into it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
2 participants