4 ms·

grep for unsafe

hnlmorg 5y ago
Take a look at the rules this tool checks for and then consider that these are only a subset of rules a mature vulnerability checker would test for. Next to none of those conditions would be caught by "grep[ing] for unsafe". The problem with software engineering is there are a thousand ways you can accidentally do something wrong when writing and deploying software in a secure environment.
- tialaramex 5y ago
  This tool checks 30 things. One of those thirty is literally "G103: Audit the use of unsafe block" Is it a coincidence? Nope, sure enough Go's "unsafe" is closely related to the unsafe concept in Rust, it allows you to defeat type safety promises in Go. Go's promises are much weaker than Rust's but it surely does make sense to audit the use of these features and the same goes for Rust's "unsafe" keyword. OK. But the other 29 aren't related right? Not so fast. "G601: Implicit memory aliasing of items from a range statement" is in fact about memory aliasing. You can't introduce such aliases in Rust... from safe code. But your unsafe code can introduce an alias that shouldn't exist and thereby introduce incorrect behaviour. Now, the Go lint for G601 has a lot of false positives. Practical experience tells us that this causes two problems, and in many cases they get out of control. One is, some people begin causing false positives without knowing it, their code is fine but is always flagged by this check, making it a nuisance. The second is, because it's a nuisance, it becomes trivial for developers to ignore it. "Just another false positive" and so it ceases to have practical value. There are a whole bunch of things here that are orthogonal to "grep for unsafe" and should be in a security-focused linter for Rust, but in fact two of these thirty rules are just "grep for unsafe" in Rust.
  - hnlmorg 5y ago
    I really can't tell if you're intent was to debunk my comment (the tone reads that way but tone can be misinterpreted) however your conclusion ends up making the same point I raised.
- decodebytes 5y ago
  Not sure, if you're aware. I was replying to the comment asking for the same tool, but for rust.
  - hnlmorg 5y ago
    Yes I was aware :)

grep for unsafe

Take a look at the rules this tool checks for and then consider that these are only a subset of rules a mature vulnerability checker would test for. Next to none of those conditions would be caught by "grep[ing] for unsafe". The problem with software engineering is there are a thousand ways you can accidentally do something wrong when writing and deploying software in a secure environment.

tialaramex 5y ago
This tool checks 30 things. One of those thirty is literally "G103: Audit the use of unsafe block" Is it a coincidence? Nope, sure enough Go's "unsafe" is closely related to the unsafe concept in Rust, it allows you to defeat type safety promises in Go. Go's promises are much weaker than Rust's but it surely does make sense to audit the use of these features and the same goes for Rust's "unsafe" keyword. OK. But the other 29 aren't related right? Not so fast. "G601: Implicit memory aliasing of items from a range statement" is in fact about memory aliasing. You can't introduce such aliases in Rust... from safe code. But your unsafe code can introduce an alias that shouldn't exist and thereby introduce incorrect behaviour. Now, the Go lint for G601 has a lot of false positives. Practical experience tells us that this causes two problems, and in many cases they get out of control. One is, some people begin causing false positives without knowing it, their code is fine but is always flagged by this check, making it a nuisance. The second is, because it's a nuisance, it becomes trivial for developers to ignore it. "Just another false positive" and so it ceases to have practical value. There are a whole bunch of things here that are orthogonal to "grep for unsafe" and should be in a security-focused linter for Rust, but in fact two of these thirty rules are just "grep for unsafe" in Rust.
- hnlmorg 5y ago
  I really can't tell if you're intent was to debunk my comment (the tone reads that way but tone can be misinterpreted) however your conclusion ends up making the same point I raised.
decodebytes 5y ago
Not sure, if you're aware. I was replying to the comment asking for the same tool, but for rust.
- hnlmorg 5y ago
  Yes I was aware :)