freenode
2m agoRoy Arends proposes relaxing DELEXT so future delegation types can coexist with NS records without requiring DELEG. 4m agoRust interrupt-disable primitives and SpinLockIrq reviewed by Peter Zijlstra with multiple code-level questions. 5m agoMan-pages maintainer proposes documenting mem*/strn* functions under <memory.h> to discourage string misuse; thread debates header semantics and editorializing. 7m agoApache NiFi publishes medium-severity CVE-2026-68979 for missing authorization on Parameter Context updates affecting referencing components. 7m agoActive discussion of new PEP 842 on __export__ for module visibility, with debate on soft keywords vs decorators. 8m agoNixOS org members dispute whether one contributor's opt-out request for The Stack dataset binds the project and whether a vote is required. 8m agoPatchset makes per-VMA locks unconditional on all configs and drops fallback paths in binder/net code. 19m agoBackport of TLS async decryption separation fix with CVE-2024-58240 to 5.15 stable tree. 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.