Monday, June 29, 2026

Packaging Council Inaugural Election Dates

With the recent approval of PEP 772 – Packaging Council governance process, a new Python Packaging Council (PPC) is being established with broad authority over packaging specifications and the mandate to coordinate Python packaging efforts. The election of the inaugural PPC will be held in parallel to the 2026 Python Software Foundation (PSF) Board election.

What is the Python Packaging Council?

The PPC will be the technical decision making body for the interoperability specifications affecting how Python packages are built, distributed, and installed.


The council will also serve as a coordinating body for the Python packaging ecosystem, working with many stakeholders from the wider Python community toward an ever-improving packaging user experience. This will include the maintainers of various packaging tools like the Python Packaging Authority (PyPA), the Python core team, the Python Steering Council, and the PSF.

Election Overview

The 2026 inaugural election fills all five seats on the PPC. The two candidates receiving the highest number of votes shall be designated Cohort A with a two-year term, and the three candidates receiving the next highest number of votes shall be designated Cohort B with a one-year term.


In future elections, each cohort will be elected for a full two-year term in alternating years, so that roughly half of the PPC turns over each cycle.

Election Timeline

The PPC election follows the same timeline as the PSF Board election:


  • Nominations open: Tuesday, July 28th, 2:00 pm UTC

  • Nomination cut-off: Tuesday, August 11th, 2:00 pm UTC

  • Announce candidates: Thursday, August 13th

  • Voter affirmation cut-off: Tuesday, August 25th, 2:00 pm UTC

  • Voting start date: Tuesday, September 1st, 2:00 pm UTC

  • Voting end date: Tuesday, September 15th, 2:00 pm UTC

Voting

You must be a Contributing, Supporting, or Fellow member by August 25th and affirm your intention to vote to participate in this election.


Check out the PSF membership page to learn more about membership classes and benefits. You can affirm your voting intention by following the steps in the PSF’s video tutorial:


  • Log in to psfmember.org

  • Choose “Your Memberships” page at the top right to check your eligibility to vote (You must be a Contributing, Supporting, or Fellow member)

  • Choose “Voting Affirmation” page at the top right

  • Select your preferred intention for voting in 2026 (which now includes a second affirmation regarding your intention to vote in the PPC election)

  • Click the “Submit” button


Like the PSF Board elections, casting a vote in a PPC election will automatically affirm your intention to participate in the next PPC election.


If you have questions about membership, please email pc-elections@python.org.

Election communications from psfmember.org

PSF Members should review their communication preferences on psfmember.org if you would like to opt in or out of receiving emails about the PSF Board, PPC elections, or both. Here’s how:



If you had previously opted out of communications from the PSF through psfmember.org and would like to review or change your preference, we encourage you to update them using the instructions above. The PSF only sends a handful of election and fundraising related communications every year via psfmember.org

Running for the Packaging Council

Do you have a vision for improving the Python packaging experience? Do you make the tools used to build and consume Python packages? Are you passionate about building communities, consensus, and standards focused on the user experience? If these resonate with you, and you have the time to attend regular meetings and participate in the standardization process, you should consider running for the inaugural PPC!


We're looking for candidates who can build bridges between projects and communities, who enjoy working with a very large community of passionate volunteers, and have a willingness to represent the wider community ahead of any single tool, project, or employer. We also welcome candidates who have a diverse set of skills and experiences, including open-governance experience, community stewardship, fundraising knowledge, and (of course!) technical expertise in Python packaging and distribution.


PEP 772 does provide non-binding operational suggestions, which hint at how the council could function. As this is the inaugural PPC, the individuals serving on it will be establishing the initial operating procedures, scope, interests, and agenda that future councils will build upon. Notably, "establishing specific processes for [the] Packaging Council and PyPA relationship" is something that the inaugural Packaging Council is expected to do.


You can nominate yourself or someone else. If you're nominating someone else, we'd encourage you to reach out to them first to make sure they're excited about the opportunity and give them a heads up that they'll need to submit their own nomination statement too. Nominations open on Tuesday, July 28th, 2:00 pm UTC, so you have time to talk with potential nominees, research the role, and craft a nomination statement for yourself or others. Remember, nominees must themselves be PSF voting members, and nomination statements must include information about the nominee’s relevant affiliations.

Tuesday, June 23, 2026

Mitigated API authentication bypass for python.org download metadata

This post is a cross-post from the Python Insider Blog.

Summary

On February 23rd 2026, Splitline Ng from the DEVCORE Research Team reported to the Python Security Response Team (PSRT) an authentication bypass vulnerability in the “python.org” release management API. By supplying an admin username with an arbitrary API key the request was processed with admin privileges.

If exploited, this would have allowed an attacker to modify Python release and file metadata that affects what URLs users are offered when visiting python.org/downloads. While it would not enable existing release files to be modified in-place, it would enable an attacker to modify the URLs that are provided on python.org for each release file, including verification material URLs. There is no evidence this vulnerability was exploited after auditing logs and database backups. This scenario is even more unlikely to have happened unnoticed due to the many redistributors requiring Python Sigstore and PGP materials be verified prior to builds.

Details

PSRT confirmed the vulnerability on a local instance of python.org. Seth Larson and Hugo van Kemenade developed and deployed the patch to production with help from Jacob Coffee. Less than 48 hours after the initial report the PSRT and the reporter confirmed that the proof-of-concept provided by the reporter no longer worked locally or on the production deployment.

This vulnerability was likely never exploited. However due to the age of the vulnerability (existing in the codebase since 2014) we don’t have absolute certainty beyond our logs and database backups. We believe attempts to exploit this vulnerability would have been “loud” and discovered quickly given the number of downstream tools and distributions automatically verifying the Sigstore and PGP materials.

We confirmed that all artifacts on python.org had not been modified by verifying Sigstore and PGP materials. Our own workflow verifying all Sigstore signatures did not signal any changes to artifacts from years prior. While verifying PGP materials we were able to verify all signatures where keys are still readily accessible from Python 2.5 to 3.13. Note that Python 3.14 and onwards no longer provide PGP materials, so these were verified with Sigstore.

The codebase was manually audited and additional hardening was applied. In addition to manual auditing, LLM auditing tools were unable to find additional issues with authentication. The delay between the initial finding and publishing of this final report was to give ample time for auditing for other issues related to authentication, to receive access to LLM auditing tools, and to arrange and complete a third-party audit from Trail of Bits prior to publication of this report. Full results from the Trail of Bit audit will be published soon.

Remediations

  • Patch applied and deployed to ensure behavior is not mixed between the “guest” authentication mode and API key authentication. This fixes the issue and documents clearly the branch in behavior between the two cases. (python/pythondotorg#2946). Trail of Bits audit improved this functionality to require HTTPS URLs for newer releases (python/pythondotorg#3014) through a custom field validator.
  • Added test cases for all negative authentication branches.
  • Database and API now reject URLs which do not start with “https://www.python.org/”. This additional hardening will reject attacker-controlled URLs even if authentication or authorization is circumvented. (python/pythondotorg#2947)
  • Increased logging retention from 3 days to 30 days for requests to python.org. This will aid in audit work for any follow-up reports.

Timeline

  • February 23rd: Report received from DEVCORE Research Team.
  • February 23rd: Report acknowledged and confirmed by PSRT.
  • February 24th: Patch reviewed and applied to python.org.
  • February 24th: Patch confirmed working by DEVCORE Research Team.
  • February 25th: Audit of logs, database backups, Sigstore and PGP completed, showing no exploitation. Codebase was manually audited by staff.
  • April 23rd: LLM security auditing tools were applied to the codebase, finding no issues related to authentication or authorization.
  • June 1st-5th: Trail of Bits audit of python.org and Python release process.
  • June 23rd: This final report is published.

Acknowledgements

Thanks to Splitline Ng from the DEVCORE Research Team for responsibly disclosing this vulnerability and confirming the remediation.

Funding for the follow-up third-party audit was provided by OpenAI. The audit and mitigations were completed by Trail of Bits, with special thanks to Facundo Tuesca and Eric Quintero. Audit results and mitigations were reviewed and applied by Seth Larson. Seth Larson's role as Security Developer-in-Residence at the Python Software Foundation is supported by Alpha-Omega.

If your organization wants to support security at the Python Software Foundation through the Developers-in-Residence program please reach out to sponsors@python.org.