In the last year CVEs have increased 3x for Python and its package manager Pip, according to Python's security developer in residence Seth Larson. "And the amount of malware published and removed from the Python Package Index (PyPI) is up 60%." Securing Python's ecosystem is getting more complex, he writes, especially given "the evolving role of AI in both security risks and security response." Their response includes bringing on a new Security Developer "to address the increasingly demanding scale of security response for the Python ecosystem." Providing prompt security response services and innovating to prevent future threats... is more difficult now than ever before... [Security developer Brett Smith] will help us keep pace with critical ongoing work such as vulnerability remediation, providing vulnerability data as a CVE Numbering Authority, and removing malware from PyPI. He'll also give the team bandwidth for new projects such as scaling PyPI's autonomous quarantine program to reduce manual effort on malware remediation and streamlining processes for the PSRT to handle the new vulnerability report volume. The role was made possible by an "ecosystem security" grant from Anthropic. And having the new security developer "will both build capacity for security work the PSF already does and enable new, proactive work," concludes Python's security developer in residence. (He discussed Python's security challenges in a June presentation with Python security engineer Mike Fiedler> .) In June, Curl's Daniel Strenberg reported Curl's CVEs have also tripled.

Read more of this story at Slashdot.

Python's security developer-in-residence Seth Larson reports from this year's official core developer Python Language Summit: "No one said 'don't do this' last year". After testing the waters at PyCon US 2025, [software engineer] David Hewitt returned to the Python Language Summit asking what Python core developers want from Rust, along with proposed timelines, phases, and success criteria for how the Rust for CPython project might proceed and become a permanent fixture within the CPython project. David is acting as an "ambassador" for the Rust for CPython project team, which is currently led by core developers Kirill Podoprigora and Emma Smith as authors of the Rust for CPython PEP draft. Emma also spoke at PyCon US 2026 about the Rust for CPython project. The team itself is around 60 developers in a Discord channel, among them a "few [Python] core developers" and a "delegation from the Rust project". The team has experience with previous projects integrating Rust into existing codebases, such as Android and the Linux kernel, and is "excited by the work and keen to support [the project] if we proceed". Showing how adopting Rust may specifically help CPython, David noted how the number of issues labeled with " type-crash" has been steadily rising over time... David explained that Jeff Vander Stoep described Rust in Android as "move fast and fix things", and that "fewer revisions for patches of the same size" was the experience Android has had since adopting Rust.... One of the biggest concerns from a year ago was Rust's lack of platform support compared to CPython, which at the time of writing officially supports 20 different architectures and platforms at either Tier 1, 2, or 3. David shared that Rust's support of different platforms has "widened since last year" and was becoming "less and less of a concern". The proposal would be to ask Python distributors to attempt using the optional Rust support in Python 3.16 (October 2027) and report platform-specific issues upstream in time to be resolved around the Python 3.17 timeline (October 2028)... [T]he first Rust code to ship in Python would be in Python 3.16 [October 2027], where it would be completely optional, with the existing C code kept as a fallback. The earliest that Rust would become required to build CPython is Python 3.18 in 2029, at least three years away... The Rust for CPython team has selected the zlib module as the first module to be given an optional Rust implementation because they "wanted to achieve a significant improvement" with a "small scope". The proposed Rust implementation will use zlib-rs, which is "heavily tested and used by the Firefox, uv, and Cargo" projects and "faster than zlib and zlib-ng on many platforms".... This small change would have an impact: the zlib compression algorithm is "widely used by Python packaging", meaning that (almost) "every pip install in Python 3.16 will be sped up" if the proposal is accepted. Thanks to long-time Slashdot reader RoccamOccam for sharing the article.

Read more of this story at Slashdot.