freenode
5m agoActive discussion of new PEP 842 on __export__ for controlling module visibility, including syntax, enforcement, and library use cases. 36m agoActive pre-RFC thread explores official LTS Rust toolchain, Foundation-paid support contracts, and ecosystem MSRV effects. 58m agoProposal to add read_freeze to core::ptr using LLVM freeze for uninit memory reads without UB. 1h agoProposal to move Fedora package reviews to PR workflow on intermediate forge repo, with discussion of CI and integration blockers. 3h agoPatch refines pipe wakeups for EPOLLET consumers; Linus and Oleg debate naming and legacy semantics. 4h agoPatch widens vm_struct.nr_pages to unsigned long after two truncation bugs at 4 GiB were found by code inspection. 4h agoPython debates PEP 842 module exports and public API boundaries 4h agoEmacs core devs discuss design for conditional/dynamic keymap bindings, including interaction with help and lookup. 4h agoTLS WG chairs' rough-consensus call on ML-KEM RFC is contested over undisclosed weighting of 'expert' participants and transparency. 10h agoLinux usbio driver fixed for slab overflows and I2C hang 17h agoLean 4 kernel bug lets metaprograms forge proofs of False 34h agoKVM nested SVM drops blanket TLB flushes with per-vCPU L2 ASIDs
AnalysisInternet & Protocols2d 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.