Further improvements to cpp/weak-cryptographic-algorithm#6099
Further improvements to cpp/weak-cryptographic-algorithm#6099MathiasVP merged 15 commits intogithub:mainfrom
Conversation
No changes, and analysis time seems unaffected as far as I can tell. |
|
I'll add a change note... |
|
Added change note, fixed merge conflict (the |
MathiasVP
left a comment
There was a problem hiding this comment.
All of the changes LGTM!
Given that https://github.com/github/codeql/blob/main/cpp/change-notes/2021-05-19-weak-cryptographic-algorithm.md already documents the reduced FP rate, I think the change-note should just say something like "increased @precision of cpp/weak-cryptographic-algorithm to high". What do you think?
It does, but that was from separate changes a week or so ago. I decided it'd be simpler to write a new change note rather than figure out whether I can safely say that this change is covered by that note as well. I've added a note about the |
Co-authored-by: Mathias Vorreiter Pedersen <mathiasvp@github.com>
Further improvements to
cpp/weak-cryptographic-algorithminspired by the findings of https://github.com/github/codeql-c-team/issues/550.I've also increased the query to
@precision highin this PR - I think it's time to do this.In the tests, we lose some false positive results and nearly as many true positives; I think this is an OK tradeoff as we're targeting
@precision high.In the real world, most of the results we lose are duplicate results in supporting code that isn't really where the encryption happens, leaving better results about the same algorithms in the same projects. In a few cases we lose something I'd rather have kept, but I think that's a necessary cost to make an essentially heuristic query precise enough for the code scanning suite.
Here's an LGTM run of the new version of the query on 20 projects: https://lgtm.com/query/78447995241338225/ (these are the same first 20 projects with results from the run in https://github.com/github/codeql-c-team/issues/550 so the density of data is high, and there's some discussion on that issue).
Performance is about 70% slower than before when I run locally. Most of this is because
isFromTemplateInstantiation(and possiblyisConstant?) calculategetEnclosingElement, which slows things down the first time it's computed.CPP-Differences run: https://jenkins.internal.semmle.com/job/Changes/job/CPP-Differences/2088/