fix(server): require an executable open before acknowledging it #77

Merged
Lochnair merged 4 commits from fix/server-open-executable-params into main 2026-08-12 13:58:26 +00:00
Showing only changes of commit c833b0663d - Show all commits
+10 -3
View File
3
@@ -122,10 +122,17 @@ pub fn echo_header_len(hmac: bool, params: &Params) -> usize {
/// can genuinely carry one, and there is no datagram shorter than none — it /// can genuinely carry one, and there is no datagram shorter than none — it
/// therefore requests no space beyond the mandatory field block, exactly as /// therefore requests no space beyond the mandatory field block, exactly as
/// zero does. /// zero does.
///
/// Only the negative end is bounded. An absurdly large positive length is
/// returned as asked, and encoding a packet that size fails in the allocator
/// rather than here — on a 64-bit target every positive `i64` converts, so that
/// has always been true of a length beyond addressable memory. Capping a
/// negotiated length to something a UDP datagram can actually be belongs with
/// the deferred maximum-packet-length policy, which would apply long before
/// this conversion.
pub fn echo_packet_len(hmac: bool, params: &Params) -> usize { pub fn echo_packet_len(hmac: bool, params: &Params) -> usize {
// Saturating rather than wrapping: on a target whose `usize` is narrower // Saturating keeps the same answer on a target whose `usize` is narrower
// than the requested length, the largest representable packet is the // than the length: still unallocatable, just unrepresentable sooner.
// closest honest answer, and the encoder's own limits reject it from there.
let requested = usize::try_from(params.length.max(0)).unwrap_or(usize::MAX); let requested = usize::try_from(params.length.max(0)).unwrap_or(usize::MAX);
echo_header_len(hmac, params).max(requested) echo_header_len(hmac, params).max(requested)
} }