* 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). Unlike alt-nodejs16/18 this package still ships llhttp 2.1.6 after the whole series -- CVE-2024-22019 deliberately patches the bundled parser in place instead of rebasing it to 6.x -- so every state and error label here was re-derived on this tree and nothing was transferred from the sibling packages: 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 14 fix exists -- 14.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 2.1.6 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. Nothing that was previously toggleable becomes untoggleable (these states were unconditionally lenient before), but an operator relying on that flag to tolerate malformed framing will now get 400 responses. - CVE-2025-23167