freenode
3m agoPatch hardens uinput/uhid to reject control characters in phys paths after they enabled a libinput CVE via udev injection. 11m agoPatch documenting mem*/strn* functions under <memory.h> in man-pages triggered 127-message debate on standards and header semantics. 11m agoApache NiFi disclosed high-severity memory exhaustion CVE via gzip request decompression, fixed in 2.11.0. 11m agoRoy Arends proposes relaxing DELEXT so future delegation types can coexist with NS records without requiring DELEG. 14m agoRust interrupt-disable primitives and SpinLockIrq reviewed by Peter Zijlstra with multiple code-level questions. 14m agoHigh-severity authz flaw in Apache NiFi allows read users to submit Parameter validation requests; fixed in 2.11.0. 16m agoApache NiFi publishes medium-severity CVE-2026-68979 for missing authorization on Parameter Context updates affecting referencing components. 17m agoActive discussion of new PEP 842 on __export__ for module visibility, with debate on soft keywords vs decorators. 1h agoQEMU virtio-gpu fix stops guest leak from short control headers 2h agoNIST leans toward seed-only keys for HQC in draft FIPS 207 3h agoArm CCA protected VMs advance in KVM review 4h agoglibc 2.41 backport treats more DNS RR types as unknown
AnalysisInternet & Protocols3d ago

The IESG should reject solo ML-KEM for TLS and keep the hybrid safety net

An IETF-wide last call asks the steering group to publish pure ML-KEM key agreement for TLS 1.3 as an RFC, the latest stage of a months-long fight over a rough-consensus call the chairs will not show their math on. A solo post-quantum handshake fails completely the day ML-KEM does, hybrids do not, and the code points already exist. The IESG should reject it. Comments close 13 August.