* SECURITY UPDATE: HTTP request smuggling via improper HTTP/1 header termination in the bundled llhttp parser - debian/patches/CVE-2025-23167.patch: restore terminator validation in the loose (non-strict) state machine of the bundled llhttp, which Node compiles by default (LLHTTP_STRICT_MODE is never set). node-v16.20.2.tar.gz ships llhttp 6.0.11, but CVE-2024-22019.patch and CVE-2024-27982.patch earlier in this series rebase it to 6.1.1, so this patch is derived against — and must be applied after — that rebased parser: headers_almost_done, chunk_size_almost_done and the chunk_data_almost_done / chunk_data_almost_done_skip pair now require the LF (resp. CR then LF) after a CR instead of consuming any byte, and res_line_almost_done requires the LF after the response status line's CR, so a header block ending in "\r\n\rX" or a chunk terminated by "\rX" is rejected with HPE_STRICT instead of silently swallowing the byte and parsing the bytes that follow as a second, smuggled request; each accept/reject edge was derived from the loose machine's own goto graph rather than by copying the strict machine's labels, which are not interchangeable between the two halves (no upstream Node.js 16 fix exists — 16.x went EOL in 2023, and upstream fixed this by replacing the parser wholesale with llhttp 9; approximated from llhttp 6d04465e, PR nodejs/llhttp#234, first in llhttp v9.0.0 / Node v20.19.2) - NOTE: llhttp 6.1.1 has no LENIENT_OPTIONAL_LF_AFTER_CR flag, so unlike upstream llhttp 9 this rejection is unconditional: --insecure-http-parser can no longer restore the previous lenient framing. - NOTE: deps/undici bundles a second, prebuilt-WASM llhttp with the same defect. It is not patchable from source here and is reachable only behind --experimental-fetch (off by default); tracked separately. - CVE-2025-23167