-
Notifications
You must be signed in to change notification settings - Fork 339
Fix LDAPi vulnerability location when using ldapjs-promise #3593
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
Conversation
Overall package sizeSelf size: 5.14 MB Dependency sizes
🤖 This report was automatically generated by heaviest-objects-in-the-universe |
Codecov Report
@@ Coverage Diff @@
## master #3593 +/- ##
==========================================
+ Coverage 84.36% 84.41% +0.05%
==========================================
Files 218 218
Lines 8830 8879 +49
Branches 33 33
==========================================
+ Hits 7449 7495 +46
- Misses 1381 1384 +3
... and 7 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
a2acbc2
to
a290bed
Compare
BenchmarksBenchmark execution time: 2023-08-29 14:24:37 Comparing candidate commit a290bed in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 472 metrics, 20 unstable metrics. |
When an error is logged, its message is redacted unless it's originating from with the tracer. Previously it would only detect it as coming from within the tracer if the filepath was within the `packages` directory. This meant that some errors originating from the tracer would be redacted even though they shouldn't. This problem can be traced back to the following PR: #3593
When an error is logged, its message is redacted unless it's originating from with the tracer. Previously it would only detect it as coming from within the tracer if the filepath was within the `packages` directory. This meant that some errors originating from the tracer would be redacted even though they shouldn't. This problem can be traced back to the following PR: #3593
When an error is logged, its message is redacted unless it's originating from with the tracer. Previously it would only detect it as coming from within the tracer if the filepath was within the `packages` directory. This meant that some errors originating from the tracer would be redacted even though they shouldn't. This problem can be traced back to the following PR: #3593
When an error is logged, its message is redacted unless it's originating from with the tracer. Previously it would only detect it as coming from within the tracer if the filepath was within the `packages` directory. This meant that some errors originating from the tracer would be redacted even though they shouldn't. This problem can be traced back to the following PR: #3593
When an error is logged, its message is redacted unless it's originating from with the tracer. Previously it would only detect it as coming from within the tracer if the filepath was within the `packages` directory. This meant that some errors originating from the tracer would be redacted even though they shouldn't. This problem can be traced back to the following PR: #3593
When an error is logged, its message is redacted unless it's originating from with the tracer. Previously it would only detect it as coming from within the tracer if the filepath was within the `packages` directory. This meant that some errors originating from the tracer would be redacted even though they shouldn't. This problem can be traced back to the following PR: #3593
When an error is logged, its message is redacted unless it's originating from with the tracer. Previously it would only detect it as coming from within the tracer if the filepath was within the `packages` directory. This meant that some errors originating from the tracer would be redacted even though they shouldn't. This problem can be traced back to the following PR: #3593
When an error is logged, its message is redacted unless it's originating from with the tracer. Previously it would only detect it as coming from within the tracer if the filepath was within the `packages` directory. This meant that some errors originating from the tracer would be redacted even though they shouldn't. This problem can be traced back to the following PR: #3593 Co-authored-by: Ugaitz Urien <ugaitz.urien@datadoghq.com>
When an error is logged, its message is redacted unless it's originating from with the tracer. Previously it would only detect it as coming from within the tracer if the filepath was within the `packages` directory. This meant that some errors originating from the tracer would be redacted even though they shouldn't. This problem can be traced back to the following PR: #3593 Co-authored-by: Ugaitz Urien <ugaitz.urien@datadoghq.com>
What does this PR do?
Fixes the location for detected SQLi when code base uses
ldapjs-promise
libMotivation
Provide the correct location for detected vulnerabilities.
Plugin Checklist
Additional Notes
There is an additional change in
calculateDDBasePath
util:project_root
, which leads to the exclusion of traces fromversions
folder, used in plugins test.project_root/packages
to avoid exclusion of traces fromversions
folder.