freenode
19m agoWilly Tarreau posts patches updating kernel docs to guide AI tools toward valid security bug reports with proper versions and steps. 27m agoActive discussion of new PEP 842 on __export__ for controlling module visibility, including syntax, enforcement, and library use cases. 33m agoGCC adopts LLM contribution policy; thread debates copyright status, GPL compatibility and risk assessment. 1h agoActive pre-RFC thread explores official LTS Rust toolchain, Foundation-paid support contracts, and ecosystem MSRV effects. 1h agoProposal to add read_freeze to core::ptr using LLVM freeze for uninit memory reads without UB. 2h agoProposal to move Fedora package reviews to PR workflow on intermediate forge repo, with discussion of CI and integration blockers. 4h agoPatch refines pipe wakeups for EPOLLET consumers; Linus and Oleg debate naming and legacy semantics. 5h agoPatch widens vm_struct.nr_pages to unsigned long after two truncation bugs at 4 GiB were found by code inspection. 5h agoPython debates PEP 842 module exports and public API boundaries 11h agoLinux usbio driver fixed for slab overflows and I2C hang 18h agoLean 4 kernel bug lets metaprograms forge proofs of False 35h 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.