The solidity version pragma used in Locke.sol allows Locke.sol to be compiled with any 0.8.X version of solidity.
It is better to pick a specific version of solidity to avoid a scenario where one version of solidity is used to test the code locally and another version is used to deploy the contract.
This issue is even worse in LockeERC20.sol where the pragma allows the contract to be compiled using any version of solidity greater than 0.8.0. This is particularly bad since: 1. It is inconsistent with Locke.sol 2. LockeERC20.sol can be compiled with a version of solidity that has different semantics than the version LockeERC20.sol was developed with, potentially leading to security issues.
Proof of Concept
N/A
Tools Used
None
Recommended Mitigation Steps
Specify an exact version of solidity that is used. This is done by the original Uniswap code for example.
0xean
commented
2 years ago
Handle
mtz
Vulnerability details
Impact
The solidity version pragma used in
Locke.solallows Locke.sol to be compiled with any 0.8.X version of solidity. It is better to pick a specific version of solidity to avoid a scenario where one version of solidity is used to test the code locally and another version is used to deploy the contract. This issue is even worse inLockeERC20.solwhere the pragma allows the contract to be compiled using any version of solidity greater than0.8.0. This is particularly bad since: 1. It is inconsistent withLocke.sol2.LockeERC20.solcan be compiled with a version of solidity that has different semantics than the versionLockeERC20.solwas developed with, potentially leading to security issues.Proof of Concept
N/A
Tools Used
None
Recommended Mitigation Steps
Specify an exact version of solidity that is used. This is done by the original Uniswap code for example.