HTTP/3 (QUIC) foundation: Phase 4 (Initial packet exchange)#27880
Draft
quaesitor-scientiam wants to merge 25 commits into
Draft
HTTP/3 (QUIC) foundation: Phase 4 (Initial packet exchange)#27880quaesitor-scientiam wants to merge 25 commits into
quaesitor-scientiam wants to merge 25 commits into
Conversation
…ves) Adds QUIC varint codec, packet number encode/reconstruct (RFC 9000 §17.1 + Appendix A), and long/short header parsing (RFC 9000 §17.2/17.3) as the first buildable pieces of an HTTP/3 implementation (tracking issue vlang#27675). Adds P-256 ECDH to crypto.ecdsa and a new crypto.rsa_pss module (RSA-PSS sign/verify), both needed for the QUIC-scoped TLS 1.3 handshake landing in Phase 2 — this repo implements that handshake from scratch in pure V rather than patching vendored mbedTLS, which has no QUIC support in any released version (see the tracking issue for the full comparison). Confirms mbedTLS's X.509 parse/verify functions work standalone (no mbedtls_ssl_context), and that the existing Windows CI OpenSSL coverage already exercises the exact dependency this work adds. /vreview caught and fixed two real bugs before this landed: a wire-integer truncation in parse_long_header's token_len handling, and a minor OpenSSL leak in the new PublicKey.from_uncompressed_bytes. See vlib/net/quic/PROGRESS.md for exact phase-by-phase status and what's next, for anyone continuing this work. Co-Authored-By: WOZCODE <contact@withwoz.com>
…01 §5.2) Adds initial_secrets.v: the fixed QUIC v1 Initial salt, HKDF-Expand-Label (RFC 8446 §7.1 — the shared derivation primitive Phase 2b/2c and Phase 3 will all reuse), and derive_initial_secrets computing the client/server Initial secrets from a connection's client-chosen DCID. Verified against RFC 9001 Appendix A.1's own published test vectors, obtained directly from the raw RFC text (the WebFetch summarizer corrupted several hex values when first attempted — caught via an odd-hex-digit-count self-check, not trusted). Also chain-tests hkdf_expand_label against the same appendix's quic key/iv/hp derivations for extra coverage of the primitive itself, without adding any Phase 3 packet-protection code. /vreview: no findings — small, side-effect-free, no concurrency/unsafe/ C-interop surface in this file.
Adds tls13_keyschedule.v: the full Early -> Handshake -> Master secret chain (derive_early_secret, derive_handshake_secrets, derive_application_secrets, derive_secret for Derive-Secret itself), plus synthetic_client_hello1_hash for RFC 8446 §4.4.1's HelloRetryRequest transcript rule. exporter_master_secret/resumption_master_secret are intentionally omitted (v1 uses neither TLS exporters nor 0-RTT). Verified against RFC 8448 §3's published intermediate secrets (independent of the RFC 9001 vectors Phase 2a uses), including an end-to-end chained test and an independent recomputation proving Transcript-Hash covers only raw handshake message bytes with no record-layer framing. All vectors extracted programmatically from the raw RFC text, not hand-transcribed, after catching WebFetch's summarizer corrupt hex constants during Phase 2a. Phase-R verified: swapped the client/server hs-traffic labels, confirmed the RFC vector tests catch it, then restored. /vreview: no findings — pure, side-effect-free, no concurrency/unsafe/ C-interop surface in this file.
…r commit) Content was written and reviewed alongside the Phase 2b commit (786ee01) but got unstaged before that commit landed. Same content, separate commit.
Adds tls13_messages.v: generic TLS 1.3 handshake message wire framing
(HandshakeType enum restricted to the real RFC 8446 SS B.3 v1.3 set,
encode_handshake_message/parse_handshake_message), and the Finished message
MAC (RFC 8446 SS 4.4.4) via compute_finished_verify_data/verify_finished,
using crypto.hmac.equal for constant-time peer-data comparison.
Verified against an extended RFC 8448 SS 3 trace (EncryptedExtensions/
Certificate/CertificateVerify bytes added to the existing ClientHello/
ServerHello vectors, needed to compute the real transcript hash the
server's Finished authenticates). First extraction attempt was silently
corrupted by RFC page-break footer text ("[Page 7]", "January 2019")
landing inside the Certificate line range and being parsed as hex bytes;
caught via a byte-count mismatch and a failed end-to-end cross-check before
trusting the vector.
Phase-R verified: forced verify_finished to always return true, confirmed
three negative tests (tampered data, wrong base secret, stale transcript
checkpoint) all caught it, then restored the real constant-time comparison.
Remaining Phase 2c work (quic_transport_parameters, ClientHello/ServerHello/
Certificate construction+parsing, the client state machine) tracked in
PROGRESS.md, not yet started.
/vreview: no findings.
…load Adds transport_parameters.v: all 17 RFC 9000 SS18.2 transport parameters (including the nested preferred_address struct) as a single QuicTransportParameters struct using Optional fields so "absent" stays distinct from "present with a default/zero value" -- applying the spec's stated defaults is deferred to whichever later phase actually consumes these values. decode_transport_parameters ignores unrecognized parameter IDs per RFC 9000 SS7.4.2's MUST (also exercises the SS18.1 grease pattern), validates ack_delay_exponent/max_udp_payload_size/max_ack_delay/ active_connection_id_limit against the spec's own bounds (accept+reject boundary-pair tests for all four), and rejects duplicate parameter IDs (a defensive addition beyond an explicit RFC citation, Phase-R verified). This is the first Phase 2 file that parses a loop of peer-controlled wire bytes, so particular attention went to the length-bounds check: it validates in u64 space before any truncating cast to int, the same pattern already fixed once in Phase 1's header.v (a crafted oversized varint length silently wrapping past a 32-bit int bounds check) -- confirmed not reintroduced here. Scope note: this file covers only the RFC 9000 SS18 "Transport Parameters" sequence itself (the extension_data). The outer TLS extension_type=0x39 + length-prefix wrapping, and the initial_source_connection_id-vs-packet- header-SCID cross-check, are later work (ClientHello/EncryptedExtensions and Phase 9's QuicConn respectively). /vreview: no findings.
Adds tls13_client_hello.v: build_client_hello constructs a complete TLS 1.3 ClientHello (RFC 8446 SS4.1.2) -- legacy_version 0x0303, empty legacy_session_id (RFC 9001 SS8.4 prohibits TLS 1.3 middlebox compatibility mode over QUIC), a single cipher suite (TLS_AES_128_GCM_SHA256), and six extensions: server_name, supported_versions, supported_groups (secp256r1 only), signature_algorithms (ECDSA P-256 + RSA-PSS), key_share (Phase 1's P-256 ECDH), and quic_transport_parameters (wrapping Phase 2c part 2's payload). Verified via two exact RFC 8448 SS3 cross-checks (supported_versions, and server_name with hostname "server") -- real sub-structures RFC 8448's own ClientHello happens to share byte-for-byte with ours despite the overall messages differing (x25519 vs our P-256, no QUIC extension there) -- plus hand-derived structural tests for the P-256-specific extensions and a full-message structural round trip using a real generated ECDH key. /vreview caught and fixed a real gap: QuicTransportParameters deliberately doesn't reject the four server-only fields itself (documented as "the client-side caller's job" in transport_parameters.v) -- build_client_hello is that caller and hadn't actually done it, so a caller could silently produce a ClientHello violating RFC 9000 SS18.2's "a client MUST NOT include any server-only transport parameter." Fixed with four explicit checks, one per field; Phase-R verified by deliberately mixing up which field one check tested and confirming exactly the corresponding test (and no other) failed. Also traced through a potential wire-integer overflow in the key_share/ server_name extension encoders (the same bug class already fixed once in Phase 1's header.v) -- confirmed unreachable: the outer encode_extension length check is a strict superset of the inner field's own overflow condition, so it always catches oversized input first. Not a finding, but worth the record given that bug class's history in this codebase. /vreview: 1 finding, fixed (see above).
Adds tls13_server_hello.v: generic TLS extension-list parsing (parse_extension_list/find_extension, RFC 8446 SS4.2, duplicate-extension rejection mirroring transport_parameters.v's duplicate-ID rejection for the analogous QUIC TLV sequence). parse_server_hello returns a ParsedHelloRetryRequest | ParsedServerHello sum type, distinguished by RFC 8446 SS4.1.3's magic Random value -- independently verified via a live SHA-256 computation of "HelloRetryRequest", not just transcribed from the RFC text. Validates every statically-checkable RFC 8446 SS4.1.3 MUST. parse_encrypted_extensions rejects early_data (0-RTT not offered). Verified against RFC 8448 SS3's own ServerHello for the happy path, plus hand-built HRR (with and without cookie) and error-path tests. Phase-R verified the HRR-vs-ServerHello discrimination itself (not just that both shapes parse), by forcing the branch and confirming the RFC-vector test catches it. /vreview caught and fixed a real gap: the real-ServerHello key_share branch didn't reject an empty key_exchange, even though RFC 8446 SS4.2.8's opaque key_exchange<1..2^16-1> requires at least 1 byte -- the parallel check already existed for the cookie extension but was missed here. Fixed with an explicit check, Phase-R verified. Deferred to Phase 2c's still-pending state machine (needs connection-level state this parsing layer doesn't have): second-HRR rejection, and cross-checking EncryptedExtensions/cipher_suite/selected_version/key_share group against what was actually offered rather than fixed v1 values. /vreview: 1 finding, fixed (see above).
…arsing Adds tls13_certificate.v: parse_certificate (RFC 8446 SS4.4.2 -- certificate_request_context + a non-empty CertificateEntry chain, each a non-empty DER cert_data plus per-entry extensions), parse_certificate_verify (RFC 8446 SS4.4.3 -- algorithm validated against v1's own fixed offered set, signature bytes), and certificate_verify_signed_content (RFC 8446 SS4.4.3's exact 64-byte-pad + context-string + separator + transcript-hash construction). Verified byte-for-byte against RFC 8446's own CertificateVerify worked example (transcript hash = 32 bytes of 0x01), extracted programmatically and independently reconstructed before use. Phase-R verified the algorithm-allowlist check. /vreview caught and fixed an over-strict check: this file initially rejected a zero-length CertificateVerify signature, but RFC 8446 SS4.4.3 declares opaque signature<0..2^16-1> -- zero is syntactically legal, unlike cert_data<1..2^24-1> and key_exchange<1..2^16-1> (real minimums of 1, correctly enforced elsewhere in this file and in tls13_server_hello.v). No real implementation ever sends an empty signature, so this wasn't an active interop break, but it was inconsistent with this file's own exact-RFC-fidelity approach -- removed, test now asserts acceptance at that boundary instead. Deliberately NOT yet built, as its own next step: the actual mbedTLS X.509 chain validation and mbedtls_pk_verify_ext signature verification this parsed data feeds into. /vreview: 1 finding, fixed (see above).
Adds net.mbedtls/x509_standalone.v: build_certificate_chain/ verify_certificate_chain/free_certificate_chain, standalone (no mbedtls_ssl_context, same discipline as Phase 0's x509_standalone_test.v). New public API added to net.mbedtls rather than net.quic reimplementing C bindings -- matches how net.http's TLS clients already depend on net.mbedtls instead of duplicating it. net.quic/tls13_certificate_chain.v wraps this for a ParsedCertificate. Every C-interop calling convention verified against mbedTLS's actual vendored source (x509_crt.c), not memory: DER certs need their exact length, not the +1 NUL-terminator convention this module's PEM helpers use (a real out-of-bounds read otherwise, though only source-verified, since mbedTLS's DER parser tolerates a too-long buflen for well-formed input and no test can observe the difference); mbedtls_x509_crt_parse_der always copies its input; repeated parse calls on the same chain correctly append via a walk-to-tail-and-link algorithm (also source-verified only -- no second real test cert exists yet to exercise a genuine multi-cert chain functionally). /vreview caught and fixed two real issues: (1) VerifiedCertificateChain.free() was double-free-prone on a second call -- the exact class of bug SSLConn.shutdown() already guards against with a documented comment, a sibling that should have been checked first; fixed with a mut receiver that nulls the pointer after freeing (also only reasoning-verified, same as above -- a double-free this size doesn't reliably crash this platform's allocator either way). (2) verify_certificate_chain's CA-bundle parse check used `< 0`, inconsistent with every other PEM-parsing call site in net.mbedtls (`!= 0`) -- a real gap, since mbedtls_x509_crt_parse can return a positive count of certs that failed to parse within an otherwise-valid bundle; `< 0` would have silently accepted that. Fixed to `!= 0`. Also resolves the plan's flagged open question about mbedTLS's PSS salt-length semantics, ahead of building the code that needs it: checked the vendored mbedtls_config.h -- MBEDTLS_USE_PSA_CRYPTO is disabled, so mbedtls_pk_verify_ext's "salt length not verified under PSA crypto" caveat doesn't apply here. No rsa_pss module fallback needed. Deliberately not yet built: the mbedtls_pk_verify_ext CertificateVerify signature verification itself (needs a small C shim to safely extract the leaf cert's embedded public key, following the established mbedtls_helpers.h pattern), and CertificateRequest rejection. /vreview: 2 findings, both fixed (see above).
…cation Adds mbedtls_pk_verify_ext-based signature checking, completing the last unbuilt piece of Certificate/CertificateVerify handling before the client state machine. net.mbedtls gains get_leaf_public_key/verify_ecdsa_signature/ verify_rsa_pss_signature (x509_standalone.v) plus a v_mbedtls_x509_crt_get_pk C shim (mbedtls_helpers.h) to safely extract a parsed cert's embedded public key. net.quic's VerifiedCertificateChain gains verify_certificate_verify_signature, dispatching CertificateVerify's algorithm to the matching digest and feeding certificate_verify_signed_content's already-tested RFC 8446 §4.4.3 construction. RSA-PSS salt length is pinned to the exact digest length per RFC 8446 §4.2.3, confirmed real (not a PSA-crypto no-op) by reading rsa.c and cross-checked against mbedTLS's own TLS 1.3 code doing the identical thing. Tested with a genuine RSA-PSS sign+verify round trip using the repo's existing self-signed test cert's matching private key (real cryptography, not just reasoning about C-binding correctness); no EC key exists anywhere in this repo, so ECDSA is tested only via rejecting an incompatible key type, documented as an honest coverage gap. /vreview caught and fixed a real bug: calling verify_certificate_verify_signature on an already-freed chain dereferenced a garbage near-null pointer (UB) instead of erroring cleanly. Phase-R confirmed a real, reliable segfault via an isolated probe before fixing; closed with a nil guard and a permanent regression test. Co-Authored-By: WOZCODE <contact@withwoz.com>
Adds Tls13ClientHandshake, wiring ClientHello construction through the client's own Finished message: process_server_hello (real ECDHE + Handshake secret derivation, handling both ServerHello and HelloRetryRequest), process_encrypted_extensions (transport-parameter extraction + initial_source_connection_id cross-check), process_certificate_or_request (chain verification, CertificateRequest rejection), process_certificate_verify (signature check against the transcript checkpoint Certificate left behind), and process_finished (server Finished verification, Application secret derivation, client's own Finished). TlsAlert + tls_alert_to_quic_error implement RFC 9001 §4.8's alert-to-CONNECTION_CLOSE mapping; every fatal path carries the mapped code via error_with_code. Second-HelloRetryRequest rejection is implemented; a first HRR is reported as explicitly not-yet-implemented rather than half-built, since it needs a cookie extension build_client_hello doesn't speak yet. Tested end-to-end with a genuine fake TLS 1.3 server: real ECDHE, real RSA-PSS CertificateVerify signing, real Finished HMACs computed independently and cross-checked against the client's own output — both sides agreeing, not just "didn't crash". Certificate chain trust itself isn't exercised end-to-end (no CA-flagged test cert exists in this repo, same gap as Phase 2c part 6); one test asserts the expected propagated failure, another installs an already-verified chain directly to test the remaining steps independently. /vreview caught and fixed two bugs: free() had no idempotency guard, and a second call double-freed the ephemeral ECDHE key (Phase-R confirmed a real, reliable crash, unlike this codebase's other double-free discussions); and certificate_request_context's RFC 8446 §4.4.2 must-be-empty requirement was parsed but never checked. Both have regression tests confirmed to fail on the pre-fix code. Co-Authored-By: WOZCODE <contact@withwoz.com>
Adds vlib/net/quic/testdata/tls13_vectors/: a real QUIC+TLS 1.3 handshake captured from Cloudflare quiche (cloudflare/quiche-qns, pinned by digest via quic-interop-runner's published image reference), running client + server + tcpdump in Docker with SSLKEYLOGFILE set (undocumented but functional for quiche, confirmed empirically). Decrypted and dissected with tshark 4.6.6 using the keylog; extract_handshake.py reconstructs each handshake message's exact raw bytes from tshark's PDML tree, cross-checked against tshark's own independently-reported size for every message before being trusted (this caught two real bugs in the extraction script itself, documented in the README). tls13_quiche_vector_test.v parses every real captured message with this module's own production functions and validates exactly what a standard keylog capture can prove: message parsing against an independent implementation's real wire bytes; a real ECDSA P-256 CertificateVerify signature verifying successfully (closing the gap Phase 2c's own signature work documented — no EC private key exists anywhere in this repo, so x509_standalone_signature_test.v could only exercise ECDSA rejection, never a genuine accepted signature); and both directions' real Finished MACs using the keylog's real traffic secrets. Documents honestly what this capture does NOT prove (the Early/Handshake Secret HKDF chain itself, which needs the raw ECDHE shared secret a standard keylog doesn't export — already covered separately via RFC 8448's worked values). Directory structure follows this repo's own crypto/blake2b/testdata/ convention rather than inventing a new one. Co-Authored-By: WOZCODE <contact@withwoz.com>
Implements RFC 9001 §5: QuicPacketProtectionKeys derivation, AEAD encrypt/decrypt with a full-packet-number nonce, and combined protect_packet/unprotect_packet helpers that hard-code the correct encrypt-then-sample-then-mask ordering. /vreview found and fixed two gaps: unprotect_header was missing the RFC 9000 §17.2/§17.3.1 Reserved Bits validation, and packet_protection_nonce indexed its iv parameter with no length check (unlike the sibling hp_key check on the same struct), risking a panic instead of a clean error. Both have regression tests. Includes a known-answer test against a real Client Initial packet extracted directly from the same quiche pcap capture Phase 2c used. Co-Authored-By: WOZCODE <contact@withwoz.com>
Adds frame.v (PADDING/PING/ACK/CRYPTO/CONNECTION_CLOSE, RFC 9000 §19), crypto_stream.v (per-level CRYPTO frame reassembly tolerating out-of-order/overlapping retransmissions, RFC 9000 §19.6), coalesce.v (datagram splitting via Length-field walking, RFC 9000 §12.2), retry.v (client-side Retry Integrity Tag, RFC 9001 §5.8, fixed key/nonce cross-checked against RFC text and quiche's own source), and version_negotiation.v (RFC 9000 §6.2 client-side handling). /vreview found and fixed three gaps: split_coalesced_datagram misread trailing UDP-level padding as a bogus packet (neither parse_long_header nor parse_short_header validated the Fixed Bit, header.v now does); parse_ack_frame sized an allocation off an unvalidated attacker-controlled ack_range_count (DoS vector); and CryptoStreamReassembler had no cap on the number of out-of-order fragments a peer could accumulate. All three have regression tests, Phase-R-verified against the pre-fix code. Includes a capstone integration test tying Phases 2+3+4 together: a real ClientHello, framed, protected, "transmitted" over an in-memory buffer, and fully reversed back to the original bytes. Co-Authored-By: WOZCODE <contact@withwoz.com>
This was referenced Jul 20, 2026
parse_version_negotiation (header.v) and find_extension (tls13_server_hello.v) were flagging CI's report-missing-fn-doc check on PR vlang#27680. No behavior change -- doc comments only. Co-Authored-By: WOZCODE <contact@withwoz.com>
Root cause of PR vlang#27680's msvc-windows/tcc-windows CI failures: both jobs run on windows-2022, unlike gcc-windows (windows-2025), and windows-2022 does not ship the OpenSSL-Win64 dev package that vlib/crypto/ecdsa/ ecdsa.c.v and vlib/crypto/rsa_pss/rsa_pss.c.v already expect via their hardcoded #flag windows search paths -- confirmed via CI logs: - msvc-windows: `LINK : fatal error LNK1104: cannot open file 'crypto.lib'` (no import library to link against) - tcc-windows: exit code -1073741515 (STATUS_DLL_NOT_FOUND) at runtime (TCC's linker is more lenient and produces an exe, but the DLL isn't discoverable at runtime) Every net.quic test file fails as a side effect, since the module transitively imports crypto.ecdsa/crypto.rsa_pss for the QUIC handshake's ECDHE key exchange. Fix: install OpenSSL via choco (which lands at the exact C:/Program Files/OpenSSL-Win64 path ecdsa.c.v/rsa_pss.c.v already check) in both jobs, and add its bin/ directory to PATH so the runtime DLL is discoverable too -- addressing both the MSVC link-time and TCC run-time failure modes with one step. No application code changes. Co-Authored-By: WOZCODE <contact@withwoz.com>
The previous commit (3524f88) guessed the choco openssl package deploys to C:\Program Files\OpenSSL-Win64\ -- confirmed wrong by the actual CI run: choco's log shows "Deployed to 'C:\Program Files\OpenSSL\'" (no -Win64 suffix), which is the SECOND of ecdsa.c.v/rsa_pss.c.v's two hardcoded #flag windows fallback paths, not the first. Point the verification/PATH-append step at the path choco actually uses. Co-Authored-By: WOZCODE <contact@withwoz.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Draft PR tracking Phase 4 of HTTP/3/QUIC support (#27675), continuing from
the completed Phase 3 work in #27877 (packet protection and header
protection, RFC 9001 §5). This branch starts from #27877's tip, since Phase
4 (Initial packet exchange) builds directly on Phase 3's packet/header
protection primitives.
This is a work-in-progress, opened as a draft so the work is
visible/discoverable while in progress. It will be retargeted to
masterdirectly once #27680 and #27877 merge; until then it necessarily also
contains their commits.
See
vlib/net/quic/PROGRESS.mdfor the exact phase-by-phase checklist.
Scope
Bootstrapping the Initial packet exchange, before 1-RTT keys exist:
crypto_stream.v— per-encryption-level CRYPTO frame reassembly, 3independent offset spaces, tolerating overlapping-duplicate
retransmissions (RFC 9000 §19.6).
frame.v— PADDING/PING/ACK/CRYPTO/CONNECTION_CLOSE frame parsing. ACK'sgap/range encoding; ACK Delay is scaled by the peer's
ack_delay_exponentand ignored for RTT purposes in Initial/Handshakespaces (RFC 9002 §5.3).
coalesce.v— datagram splitting by walking long-headerLengthfields;a short-header packet can never be followed by anything else in a
coalesced datagram; Initial datagrams padded to ≥1200 bytes (RFC 9000
§14.1).
retry.v— client-side Retry handling: validate the fixed-key RetryIntegrity Tag (RFC 9001 §5.8, a separate fixed AEAD key/nonce, not
derived from Initial secrets), switch DCID, reject a second Retry for
the same attempt (RFC 9000 §17.2.5.2).
version_negotiation.v— client-side handling; a VN packet listing v1itself is a hard protocol error from the server, not a retry trigger.
Test plan
REAL captured server datagram from Phase 3's testdata (Initial +
Handshake, 167 + 691 bytes), plus synthetic cases for stopping at a
Version Negotiation packet, a short header, and a truncated/oversized
Length field.
hand-derived numeric example with the exact expected wire bytes
hardcoded (not just decode(encode(x))==x, which can't catch a bug
consistently wrong in both directions), plus ECN counts and 4
negative/boundary tests.
original DCID are all rejected. Retry replay rejection (RFC 9000
§17.2.5.2's "accept at most one Retry per connection attempt") is
explicitly NOT implemented here:
verify_retry_integrity_tagis astateless primitive, and tracking "has this connection already
accepted a Retry" is connection-lifecycle state that belongs to
Phase 9's
QuicConn(documented on the function itself).together) over an in-memory fake transport — a real ClientHello,
framed, protected, "transmitted", and fully reversed back to the
original bytes. This is what caught the Fixed Bit gap noted below.
./vnew test <path>— 21/21files in
vlib/net/quic/../vnew fmt -wapplied to all touched.vfiles./vreview(full A-G pass) found and fixed three gaps before commit:split_coalesced_datagrammisread trailing raw UDP-level padding as abogus extra packet (neither
parse_long_headernorparse_short_headervalidated RFC 9000's Fixed Bit —
header.vnow does, a Phase 1 file fixedhere since the gap was surfaced directly by Phase 4 work);
parse_ack_framesized an allocation off an unvalidated, attacker-controlled
ack_range_count(a real DoS vector from one small ACK frame); andCryptoStreamReassemblerhad no cap on the number of out-of-orderfragments a peer could accumulate. All three have regression tests,
Phase-R-verified to fail on the pre-fix code.
🧙 Built with WOZCODE