Conversation
|
Maybe more discussion is required about the scope. ie. Looking at this comment, it appears the original intent was to support testing and benchmarking of security analysis tools. I think that's overly restrictive, and creates an obstacle to adoption. Some things are too subjective to automatically identify, but are definitely weaknesses (ie. #209). |
|
I am ok with narrowing down the scope to 'smart contract adjacent' code.
The intent as described in https://eips.ethereum.org/EIPS/eip-1470 is to define weaknesses that are specific to smart contracts and to develop a way to create test cases so that auditors and tools alike have a way to identify them in the code samples. Historically most contributions came from folks that are working on tools but that does not mean though that the SWC-registry is only for tool builders. At the top of my head there are several categories of weaknesses that tools will have a very hard time in identifying ... nobody has added them yet though. |
Agree.
Great, lots to do. :) |
* Add details to requirement_simple bytecode locations * Tweak location info for SWC-128 * misformatted bytecode offsets * Update README.md Updating links and some minor textual changes. * Slightly more descriptive error * Print full error * Clarify scope (#220) * Kaden zipfel feature/gas griefing (#222) * Insufficient gas griefing * Add newlines * Fix improper newlines * Make changes to relayer contracts * Add CWE reference * Fix link * Rename to SWC-126 * No target redeploy * Fix compiler warnings * Update SWC definition [ci skip]
2 participants
Adds the following to the README
Scope of Weaknesses
SWCs should be concerned with weaknesses that can be identified within the code of a smart contract, typically Solidity.
Weaknesses in 'smart contract adjacent' code should not be included. For example, the gas siphoning attack occurs in wallet code, and should be protected against in wallet code.