-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Rust: Update legacy MaD models 1 #19934
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
- ["core::panicking::panic_fmt", "Argument[0]", "log-injection", "manual"] | ||
- ["core::panicking::assert_failed", "Argument[3].Field[core::option::Option::Some(0)]", "log-injection", "manual"] | ||
- ["<core::option::Option>::expect", "Argument[0]", "log-injection", "manual"] | ||
- ["<core::option::Option as log_err::LogErrOption>::log_expect", "Argument[0]", "log-injection", "manual"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may be able to simplify / generalize paths such as this one, for the time being I'm trying to translate as close to mechanically as I can.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There were quite a lot of changes in tests - mostly trivial changes to MaD model strings and references, but also a handful of lost sources...
let path = e.path(); // $ MISSING: Alert[rust/summary/taint-sources] | ||
let file_name = e.file_name(); // $ MISSING: Alert[rust/summary/taint-sources] | ||
sink(path); // $ MISSING: hasTaintFlow | ||
sink(file_name); // $ MISSING: hasTaintFlow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hvitved I'm looking to get these results back. The sources go missing because there's no result for getCanonicalPath
on lines 423 and 424, I'm guessing that means we haven't inferred the type of e
/ entry
due to limitations of type inference on for
loops (line 421).
If you agree that's the problem, do you have an idea what the general case for inferForLoopExprType
should look like? I think we need to get the type of the Iterator
(returned by fs::read_dir
in this case) and pull it apart for it's Item
type.
DCA results - interestingly enough DCA does not show a loss of sources, it actually recognises a handful more, though a significant number of query sinks and 4 query results are lost. The lost results are the FPs we gained in #19881, I'm not too worried about them right now. The lost sinks I've narrowed down to the I don't think we should insist on fixing these now. I do think we need continue putting effort into getting type inference, call targets and canonical paths working in more cases to recover these losses. |
Update some legacy MaD models to the new model format. This PR does perhaps a third of the models, I have more unfinished translations locally but I want to start pushing some of this work through CI + DCA and find out if there are going to be any issues there.