suricata
suricata copied to clipboard
OISF
http: Use libhtp-rs.
Link to redmine ticket: 2696
Describe changes:
- Use libhtp-rs.
Rebased from #10764
Draft to see CI feedback with latest libhtp-rs changes, and not have too many conflicts
TODOs :
Still one oss-fuzz report for libhtp-rs to consider
There is still the big question : Where should libhtp-rs live ?
- Separate repo, released as a crate.
- Separate crate, but inside the suricata rust/ directory.
- Separate repo, as today with git clone and bundle
To summarize my thoughts in one place:
- Separate repo, released as a crate.
Ideal, but this will make it hard to always build against the main branch. Cargo.lock will pin it to a specific hash. If we want the same behavior as now, CI will have to add a step to update that crate in the Cargo.lock before building. And we'll want to make sure we commit that more regularly.
To replace the LIBHTP_REPO and LIBHTP_BRANCH vars will require some on-the-fly patching of Cargo.toml as well.
- Separate crate, but inside the suricata rust/ directory.
Given our rather tight coupling, being in the same repo solves many of the issues.
- Separate repo, as today with git clone and bundle
Easiest if we really don't want the libhtp-rs code in the Suricata repo. Keeps the current flexibility of on-the-fly libhtp version selection.
Information:
ERROR: QA failed on SURI_TLPW2_single_suri_time.
ERROR: QA failed on SURI_TLPW2_single_alerts_cmp.
ERROR: QA failed on SURI_TLPW2_autofp_alerts_cmp.
ERROR: QA failed on SURI_TLPW1_suri_time.
ERROR: QA failed on SURI_TLPW1_files_sha256.
ERROR: QA failed on SURI_TLPR1_alerts_cmp.
| field | baseline | test | % |
|---|---|---|---|
| SURI_TLPW2_single_stats_chk | |||
| .uptime | 772 | 820 | 106.22% |
| SURI_TLPW2_autofp_stats_chk | |||
| .flow.end.tcp_state.established | 8 | 9 | 112.5% |
| SURI_TLPW1_stats_chk | |||
| .uptime | 176 | 183 | 103.98% |
| .app_layer.error.http.parser | 47 | 2 | 4.26% |
| SURI_TLPR1_stats_chk | |||
| .app_layer.error.http.parser | 700 | 369 | 52.71% |
Pipeline 20426
