-
Notifications
You must be signed in to change notification settings - Fork 337
Upgrade libddwaf native bindings #5792
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: master
Are you sure you want to change the base?
Conversation
Overall package sizeSelf size: 9.58 MB Dependency sizes| name | version | self size | total size | |------|---------|-----------|------------| | @datadog/libdatadog | 0.5.1 | 29.73 MB | 29.73 MB | | @datadog/native-appsec | 9.0.0 | 19.6 MB | 19.61 MB | | @datadog/pprof | 5.8.0 | 12.55 MB | 12.92 MB | | @datadog/native-iast-taint-tracking | 4.0.0 | 11.72 MB | 11.73 MB | | @opentelemetry/core | 1.30.1 | 908.66 kB | 7.16 MB | | protobufjs | 7.5.3 | 2.95 MB | 5.6 MB | | @datadog/wasm-js-rewriter | 4.0.1 | 2.85 MB | 3.58 MB | | @datadog/native-metrics | 3.1.1 | 1.02 MB | 1.43 MB | | @opentelemetry/api | 1.8.0 | 1.21 MB | 1.21 MB | | import-in-the-middle | 1.14.0 | 120.58 kB | 842.2 kB | | source-map | 0.7.4 | 226 kB | 226 kB | | opentracing | 0.14.7 | 194.81 kB | 194.81 kB | | lru-cache | 7.18.3 | 133.92 kB | 133.92 kB | | pprof-format | 2.1.0 | 111.69 kB | 111.69 kB | | @datadog/sketches-js | 2.1.1 | 109.9 kB | 109.9 kB | | lodash.sortby | 4.7.0 | 75.76 kB | 75.76 kB | | ignore | 5.3.2 | 53.63 kB | 53.63 kB | | istanbul-lib-coverage | 3.2.2 | 34.37 kB | 34.37 kB | | rfdc | 1.4.1 | 27.15 kB | 27.15 kB | | @isaacs/ttlcache | 1.4.1 | 25.2 kB | 25.2 kB | | dc-polyfill | 0.1.9 | 25.11 kB | 25.11 kB | | tlhunter-sorted-set | 0.1.0 | 24.94 kB | 24.94 kB | | shell-quote | 1.8.2 | 23.54 kB | 23.54 kB | | limiter | 1.1.5 | 23.17 kB | 23.17 kB | | retry | 0.13.1 | 18.85 kB | 18.85 kB | | semifies | 1.0.0 | 15.84 kB | 15.84 kB | | jest-docblock | 29.7.0 | 8.99 kB | 12.76 kB | | crypto-randomuuid | 1.0.0 | 11.18 kB | 11.18 kB | | ttl-set | 1.0.0 | 4.61 kB | 9.69 kB | | mutexify | 1.4.0 | 5.71 kB | 8.74 kB | | path-to-regexp | 0.1.12 | 6.6 kB | 6.6 kB | | koalas | 1.0.2 | 6.47 kB | 6.47 kB | | module-details-from-path | 1.0.4 | 3.96 kB | 3.96 kB |🤖 This report was automatically generated by heaviest-objects-in-the-universe |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #5792 +/- ##
=======================================
Coverage 79.15% 79.15%
=======================================
Files 522 522
Lines 24010 23973 -37
=======================================
- Hits 19005 18976 -29
+ Misses 5005 4997 -8 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Datadog ReportBranch report: ✅ 0 Failed, 1257 Passed, 0 Skipped, 25m 36.12s Total Time |
BenchmarksBenchmark execution time: 2025-06-02 13:38:41 Comparing candidate commit 079af0e in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 1273 metrics, 50 unstable metrics. |
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.
I can't tell anything about the domain logic in this case, I just had a brief look at the overall code and left a few questions and suggestions :)
telemetryLogCh.publish({ | ||
message: diagnostics[configKey].error, | ||
level: 'ERROR', | ||
tags: { | ||
log_type: `rc::${product.toLowerCase()}::diagnostic`, | ||
appsec_config_key: configKey, | ||
rc_config_id: rcConfigId | ||
} | ||
}) |
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.
I would abstract this in a small helper with the rule of three
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.
New helper has been implemented to publish these diagnostics log messages.
for (const item of toUnapply) { | ||
const { product, id } = item | ||
if (!['ASM_DD', 'ASM_DATA', 'ASM'].includes(item.product)) continue |
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.
Right now this array is created in each loop iteration. Maybe move it outside of the method and make it a set so that there is only a single lookup happening per iteration? :)
if (!['ASM_DD', 'ASM_DATA', 'ASM'].includes(item.product)) continue | |
if (PRODUCTS.has(item.product)) continue |
The same applies in other places.
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.
Suggestion has been applied.
} catch (e) { | ||
wafUpdatedSuccess = false | ||
item.apply_state = ERROR | ||
item.apply_error = e.toString() |
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.
Is it intentional to only care about the error type and message? Calling .toString()
is pretty bad for Node.js errors such that the stack and other properties are all lost. In case the error should be inspected, I would just use util.inspect(error)
.
The same for other spots.
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.
Yes, it is. Tracer only reports error type and message in apply_error
for RC items.
- https://github.com/DataDog/dd-trace-js/blob/master/packages/dd-trace/src/remote_config/manager.js#L299
- https://github.com/DataDog/dd-trace-js/blob/master/packages/dd-trace/src/remote_config/manager.js#L314
- https://github.com/DataDog/dd-trace-js/blob/master/packages/dd-trace/src/remote_config/manager.js#L323
if (file?.custom_rules?.length) { | ||
newCustomRules.set(id, file.custom_rules) | ||
wafUpdatedSuccess = false | ||
item.apply_error = JSON.stringify(extractErrors(updateResult.diagnostics)) |
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.
The errors are handled very differently depending on where it happens while the overall logical seems to almost be identical. Should they not be handled all the same? :)
copy.data = data | ||
} | ||
return copy | ||
return Object.keys(result).length > 0 ? result : null |
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.
Instead of checking for results keys, I would just use a boolean that I set to true in case the loop happened to match something, since calling Object.keys()
is quite expensive to just get that information.
In general, is the object really arbitrary that we have to loop over it completely in an unknown way?
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.
Suggestion's been applied.
Regarding the arbitrariness of the objetc, no, the object is not really arbitrary, it has a defined schema (at least, for this version of libddwaf).
c570c22
to
9872b5d
Compare
if (this.ddwaf.diagnostics.ruleset_version) { | ||
this.rulesVersion = this.ddwaf.diagnostics.ruleset_version | ||
} | ||
const success = this.ddwaf.createOrUpdateConfig(rules, path) |
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.
createOrUpdateConfig could throw an error, I think we need a try/catch block
this.ddwaf.createOrUpdateConfig(this.defaultRules, DEFAULT_WAF_CONFIG_PATH) | ||
} | ||
|
||
return { success, diagnostics } |
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.
I think that we need to update this.rulesVersion = this.ddwaf.diagnostics.ruleset_version here too
wafUpdatedSuccess = false | ||
item.apply_state = ERROR | ||
item.apply_error = e.toString() | ||
Reporter.reportWafConfigError(waf.wafManager.ddwafVersion, waf.wafManager.rulesVersion) |
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.
This means that we gonna report probably a wrong rulesVersion if remove fails no?
This reverts commit f8d8805.
9872b5d
to
079af0e
Compare
@@ -225,6 +242,54 @@ function reportWafInit (wafVersion, rulesVersion, diagnosticsRules = {}, success | |||
incrementWafInitMetric(wafVersion, rulesVersion, success) | |||
} | |||
|
|||
function logWafDiagnosticMessage (product, rcConfigId, configKey, message, level) { | |||
telemetryLogCh.publish({ |
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.
These logs are sent via telemetry, but aren't shown in the output if the logs are enabled, is the expected behaviour?
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.
The RFC only establishes the propagation of diagnostics by telemetry and RC. Specifically it states that:
Note that aside from through telemetry logs, none of the diagnostics presented here should be logged to a regular logger using a level above debug, as it will inevitably result in customer complaints.
What does this PR do?
Introduces changes to use the latest version of native appsec which contains the libddwaf changes up to version 1.24.1.
This new libddwaf brings a new interface for instance creation as well as instance configuration management, moving the logic of merging configurations received by RC to libddwaf.
Also, diagnostics have been updated and should now be propagated by RC and telemetry.
Additional Notes
APPSEC-55565
RFC-1025