Announcing Python Software Foundation Fellow Members for Q4 2023! 🎉

The PSF is pleased to announce its fourth batch of PSF Fellows for 2023! Let us welcome the new PSF Fellows for Q4! The following people continue to do amazing things for the Python community:

Jelle Zijlstra

Github, Quora

Thank you for your continued contributions. We have added you to our Fellow roster online.

The above members help support the Python ecosystem by being phenomenal leaders, sustaining the growth of the Python scientific community, maintaining virtual Python communities, maintaining Python libraries, creating educational material, organizing Python events and conferences, starting Python communities in local regions, and overall being great mentors in our community. Each of them continues to help make Python more accessible around the world. To learn more about the new Fellow members, check out their links above.

Let's continue recognizing Pythonistas all over the world for their impact on our community. The criteria for Fellow members is available online: https://www.python.org/psf/fellows/. If you would like to nominate someone to be a PSF Fellow, please send a description of their Python accomplishments and their email address to psf-fellow at python.org. Quarter 1 nominations are currently in review. We are accepting nominations for Quarter 2 2024 through May 20, 2024.

Are you a PSF Fellow and want to help the Work Group review nominations? Contact us at psf-fellow at python.org.

New Open Initiative for Cybersecurity Standards

The Python Software Foundation is pleased to announce our participation in co-starting a new Open Initiative for Cybersecurity Standards collaboration with the Apache Software Foundation, the Eclipse Foundation, other code-hosting open source foundations, SMEs, industry players, and researchers. This collaboration is focused on meeting the real challenges of cybersecurity in the open source ecosystem, and demonstrating full cooperation with and supporting the implementation of the European Union’s Cyber Resilience Act (CRA). With our combined efforts, we are optimistic that we will reach our goal of establishing common specifications for secure open source development based on existing open source best practices. 

New regulations, such as those in the CRA, highlight the need for secure by design and strong supply chain security standards. The CRA will lead to standard requests from the Commission to the European Standards Organisations and we foresee requirements from the United States and other regions in the future. As open source foundations, we want to respond to these requests proactively by establishing common specifications for secure software development and meet the expectations of the newly defined term Open Source Steward. 

Open source communities and foundations, including the Python community, have long been practicing and documenting secure software development processes. The starting points for creating common specifications around security are already there, thanks to millions of contributions to hundreds of open source projects. In the true spirit of open source, we plan to learn from, adapt, and build upon what already exists for the collective betterment of our greater software ecosystem. 

The PSF’s Executive Director Deb Nicholson will attend and participate in the initial Open Initiative for Cybersecurity Standards meetings. Later on, various PSF staff members will join in relevant parts of the conversation to help guide the initiative alongside their peers. The PSF looks forward to more investment in cybersecurity best practices by Python and the industry overall. 

This community-driven initiative will have a lasting impact on the future of cybersecurity and our shared open source communities. We welcome you to join this collaborative effort to develop secure open source development specifications. Participate by sharing your knowledge, input, and raising up existing community contributions. Sign up for the Open Initiative for Process Specifications mailing list to get involved and stay updated on this initiative. Check out the press release's from the Eclipse Foundation’s and the Apache Software Foundation for more information.

DjangoCon Africa Grant Process Retrospective

The PSF received an open letter asking us, amongst other things, to look into some of our recent grant decisions and make recommendations to the PSF Board for improving the Grants Program. We contracted Carol Willing, of Willing Consulting, to do this work in the form of a retrospective. Carol’s scope included reading through mailing lists, examining Board and Grants Working group norms, creating a comprehensive timeline, conducting interviews, documenting findings, and offering recommendations for the future.

In the retrospective Willing contextualizes the PSF Grants Program as part of the work of a non-profit with a charitable mission, incorporating research on best practices and effective governance. The full text of the DjangoCon Africa Grant Process Retrospective is now available.  We are eager to explore the suggestions made in the retrospective and respond to community feedback.
 

 

This retrospective is just one step in our process to ensure the PSF Grants Program is responsive, transparent, and more approachable. We also recently started hosting PSF Grants Program Office Hours. The office hours are a text-only chat-based session hosted on the Python Software Foundation Discord at 1-2PM UTC (9AM Eastern) on the third Tuesday of the month. (Check what time that is for you.)  We look forward to sharing more of our progress as we continue to enhance and improve the PSF Grants Program. 

 

Announcing a PyPI Support Specialist

We launched the Python Package Index (PyPI) in 2003 and for most of its history a robust and dedicated volunteer community kept it running. Eventually, we put a bit of PSF staff time into the maintenance of the Index, and last year with support from AWS we hired Mike Fiedler to work full-time on PyPI’s urgent security needs.

PyPI has grown enormously in the last 20+ years, and in recent years it has reached a truly massive scale with growth only continuing upward. In 2022 alone, PyPI saw a 57% growth and as of this writing, there are over a half a million packages on PyPI. The impact PyPI has these days is pretty breathtaking. Running a free public service of that size has come with challenges, too. As PyPI has grown, the work of communicating with users and solving account issues here has grown in tandem and out-stripped our current volunteer plus one tenth of a staff person capacity. We also know that some community members have noticed and expressed frustration with the time-frame that goes with tasks that don't have sufficient staffing.

Much of this work is sensitive and complex such that it needs to be performed by a PSF staff person. It involves personal information and verification processes to make sure we’re giving access and names to the correct entities. Work like this needs to be done by a person who is here day after day to carry out multi-step verification procedures and is accountable to the PSF. 

We are very happy to share the news that we are hiring a person to help us manage the increased capacity and allow us to keep pace with PyPI’s seemingly unstoppable growth. This is an associate role that is 100% remote. Please take a look at this posting for a PyPI Support Specialist and share it with your networks.

White House recommends use of memory-safe languages like Python

Earlier this week the White House published a report recommending the use of memory-safe programming languages to eliminate an entire class of vulnerabilities affecting software. The report quotes claims from large software producers like Google and Microsoft which estimate that 70% of vulnerabilities affecting software are due to memory-safety issues.

Back in December of 2023, the Cybersecurity and Infrastructure Security Agency (CISA) published a report that included a list of memory-safe programming languages, among them was the Python programming language.

The Python Software Foundation’s response to the US Government's Request for Information noted Python's memory-safety and ability to wrap code written in C, C++, and Rust among other systems languages. Part of Python’s popularity stems from the large number of community-maintained packages using this feature for performance, wrapping existing libraries, and low-level API access.

Cryptography is one of the most depended on Python libraries for cryptographic primitives, installed nearly 10 million times per day. Cryptography started migrating from using C to Rust for security reasons in 2020 and made the first release with Rust binary extensions in 2021. You can listen to maintainers Paul Kehrer and Alex Gaynor discuss this non-trivial migration in their PyCon 2022 talk.

The migration of the cryptography library included tools like PyO3 and setuptools-rust that enable easier adoption of Rust binary extensions. There’s already plenty of buzz for using Rust and Python together, the adoption of Rust in Python packages is steadily increasing from the single digits in 2020 to today with hundreds of packages using Rust.

There are many opportunities to learn about writing Python binary extensions using Rust, for example, at PyCon US 2024 there will be a tutorial about getting started with PyO3 and a talk on PyO3 and maturin, a PEP 517 build backend for Rust by a maintainer of the PyO3 project.

Historically Python binary extensions were built mostly using C and C++ meaning there are many projects which, for reasons like backwards compatibility or lack of resources and time, cannot or do not want to migrate to Rust. For these projects, the use of compiler options can harden binaries against some memory safety issues. The OpenSSF Best Practices working group has published a list of compiler options to consider adopting in order to harden builds of C and C++ code.

There is still much work to be done to secure the Python ecosystem and it can’t be done without our amazing community of contributors and maintainers. We look forward to more investment in this area as part of the industries’ adoption of memory-safe programming languages. If you are interested in being part of conversations around improving security in Python, we invite you to open a thread on discuss.python.org.

Software Bill-of-Materials documents are now available for CPython

Our Security Developer-in-Residence, Seth Larson, has been working to improve the management of vulnerabilities for Python users. Seth has championed progress on this goal in a variety of areas:

• Authorizing the Python Software Foundation as a CVE Numbering Authority (CNA) to publish CVE IDs and records
• Revitalizing the security advisory mailing list (security-announce@python.org)
• Migrating all historical vulnerabilities to the Open Source Vulnerability format (OSV) and having the records indexed into the global OSV database

With the release of CPython 3.12.2, the next step of the Python Software Foundation’s vulnerability management strategy is now available in the form of Software Bill-of-Materials (SBOM) documents for CPython source releases. The documents are available for download in their own column labeled “SBOM” in the “Files” table on the release page. User documentation and a getting started guide for CPython SBOMs is available on python.org.

These documents are relatively new but have been tested with multiple tools that accept SPDX SBOM documents. Please report any feedback on the SBOM to the CPython issue tracker.

What is a Software Bill-of-Materials (SBOM)?

Software Bill-of-Materials are machine-readable documents using an ecosystem-independent format like SPDX or CycloneDX to describe what a piece of software is made of and how each component within the software relates to other components. There are multiple use-cases for SBOMs, but for CPython we primarily focused on software supply chain and vulnerability management.

Many vulnerability scanning tools support passing an SBOM document as input to provide a comprehensive scan for software vulnerabilities without needing to rely on fallible software discovery. This means there’s less chances for vulnerabilities to be missed by scanners.

There are existing tools for automatically creating SBOMs for software, but SBOMs which aren’t accurate are sometimes more dangerous than having no SBOM due to causing a false sense of security. This is especially true for complex pieces of software or projects which exist outside of package ecosystems, both of which apply to CPython and make generating an SBOM difficult. For this reason the content of CPython SBOMs is curated by hand on first pass to ensure accuracy and completeness and then automated to track updates as the software changes.

SBOM documents are becoming a requirement for compliance in multiple areas and industries. In order to meet those requirements we are providing a comprehensive and accurate SBOM for CPython that will provide assurance for Python users.

What is included in CPython SBOMs?

CPython SBOMs use the SPDX SBOM standard. SBOM documents include a description of the contained software, including all of its dependencies. Information in CPython SBOMs includes:

• Names and versions of all software components
• Software identifiers (like CPE and Package URLs)
• Download URLs for source code with checksums
• File names and content checksums
• Dependency relationships between each component

CPython SBOMs satisfy the requirements listed in the NTIA Minimum Elements for a Software Bill of Materials. Software identifiers can be used for correlating software in use to vulnerability databases like the CVE database and Open Source Vulnerability database, typically done automatically using vulnerability scanning tools.

What isn’t included in CPython SBOMs?

Keep in mind that software libraries that you supply yourself to compile CPython, such as OpenSSL and zlib, are not included in the SBOMs for source artifacts.

This is due to these libraries not being included in source artifacts, so CPython users have a choice of which version and sources to use for these third-party libraries. Folks who are compiling CPython from source are responsible for tracking their own dependencies either in a separate SBOM document or by appending new entries to your local CPython SBOM.

CPython’s SBOMs don’t include licensing information for dependencies. See the CPython licensing page for licensing information.

What is coming next for CPython SBOMs?

This is only the beginning for CPython SBOMs, as mentioned above there are only SBOM documents published for source releases today. The CPython release managers also publish binary installers for Windows and macOS on a variety of distribution channels. These artifacts will need their own SBOM documents as they are compiled with software that’s typically not available on those platforms (e.g. OpenSSL).

There’s also more infrastructure needed to reduce noise and churn for Python users and Python Security Response Team members alike. Vulnerability EXchange (VEX) statements are a set of standards which allows software producers to signal to user tooling whether a piece of software in use is affected by a vulnerability, even for vulnerabilities affecting dependencies. This is an area of active development and is being explored alongside the OpenSSF Security Tooling Working Group.

The Security Developer-in-Residence role and this work is funded by a substantial investment from the OpenSSF Alpha-Omega Project. Thanks to Alpha-Omega for their support in improving the security posture of the entire Python ecosystem.The OpenSSF is a non-profit cross-industry collaboration that unifies security initiatives and brings together leaders to improve the security of open source software by building a broader community, targeted initiatives, and best practices.

Introducing PSF Grants Program Office Hours

In October 2023, we acknowledged the situation surrounding DjangoCon Africa and noted our intent to make ongoing improvements to the Grants Program. We also recognize that we are in a new world of hybrid programming since the onset of the pandemic which comes with different funding and cost challenges. One step we are taking to refresh the Grants Program (we’ll be reporting on other steps soon) is to establish PSF Grants Program Office Hours.

The office hours will be hosted on the Python Software Foundation Discord once a month at 1-2PM UTC (9AM Eastern) on the third Tuesday of the month. (Check what time that is for you.) We invite the Python community to join in to receive support for Grant-related questions and inquiries! If you have urgent or immediate questions related to the Grants Program, please email grants@pyfound.org.

Direct line of communication

As we sat down to address the challenges and issues raised around the Grants Program and how to better support the Python community, we came to realize that refreshing the program would not be an easy and quick task. We need a two-way communication channel dedicated to the topic of grants with the PSF Board, the Grants Working Group, the D&I Working Group, the Code of Conduct Working Group, and most importantly, our vibrant and diverse community.

We believe a direct line of communication between the PSF and the worldwide Python community is the best first step. In order to create that direct line, gather your feedback, and collaborate on the future of the program, we are establishing regular PSF Grants Program Office Hours!

What’s the goal?

There are a couple of goals we hope to accomplish with the Grants Program Office Hours. In the short term, we believe recurring time supporting communication between the community and the PSF is key. In other words, a place for folks to come with questions and ideas regarding the Grants Program, with an understanding that we don’t have it perfect yet. If we have the answer, or we can point you to the right resource - amazing! If we don’t, that’s an area we know needs more work and will be added to our “To Do.”

We hope to see the office hours evolve over time as we work through feedback and make updates to our process, documentation, and resources. In the long term, the PSF hopes Grants Program Office Hours will create a place for our community to ask questions about the Grants Program and for us to have (almost) all the answers. We’d like the office hours to continue to be a place where we receive feedback from the community and continuously improve what we can do for Pythonistas around the world.

PSF Grants Program Office Hour Hosts

The PSF Grants Program Office Hours will be hosted by members of the PSF Staff. This will change over time, but for now you can expect to see Laura Graves, Senior Accountant, and Marie Nordin, Community Communications Manager, hosting the sessions. When needed, other PSF staff members will sub in for Laura and Marie.  

This sounds great! How can I join?

The PSF Grants Program Office Hours will be a text-only chat based office hour hosted on the Python Software Foundation Discord at 1-2PM UTC (9AM Eastern) on the third Tuesday of the month. The server is moderated by PSF Staff and is locked in between office hour sessions. If you’re new to Discord, check out some Discord Basics to help you get started. And as always, if you have urgent or immediate questions related to the Grants Program, please email grants@pyfound.org.

Come prepared to the Office Hours with questions and shareable links to your Grant applications drafts in progress via Google docs, etherpad, pastebin, etc. We hope to see you there!

Kicking off 2024 strong, thanks to our community!

We are starting off the year feeling energized and supported, thanks to each of you who shared or donated to our year-end fundraiser and membership drive. We raised a whopping $43,000 through our PyCharm partnership with JetBrains–that’s more than double last year! With over 150 individual donations, new Supporting Memberships, and JetBrains’ generous partnership, we raised $134,175 total for our work supporting Python and the Python community! All in all, during the period of the fundraiser, we raised close to $200K, which includes donations from our sponsors, donations to our Fiscal Sponsorees, Membership renewals, and proceeds from the special replay of our Humble Bundle, thanks to No Starch Press.
 

Your generous support means we can confidently start 2024 by investing in our key goals for the year. These goals include:

• Improving dialogue with the global community

• Investing in community support

• Creating more pathways for technical contributions

We rely on community investment–of money, but also time, energy, ideas, and enthusiasm–to reach each of these goals. 

Supporting Membership is a great way for the community to invest in the PSF’s work. It was exciting to see many new Supporting Members made use of our sliding scale rate option to become Members. Welcome aboard, new members, and thank you for joining us! We’re looking forward to having your voice take part in the PSF’s future.

Because the PSF doesn’t buy lists or ads, your help in sharing our fundraiser with your networks makes a big difference, and we really appreciate how many of you took the extra time to help promote it. We’re excited about where 2024 will take us together, and as always, we’d love to hear your ideas and feedback. Looking for how to keep in touch with us? You can find all the ways in our "Where is the PSF?" blog post.


Wishing you all a wonderful & Python-filled new year!
- The PSF Team

Announcing Python Software Foundation Fellow Members for Q3 2023! 🎉

The PSF is pleased to announce its third batch of PSF Fellows for 2023! Let us welcome the new PSF Fellows for Q3! The following people continue to do amazing things for the Python community:

Dustin Ingram

LinkedIn, Github, Social, Website

Marlene Mhangami 

Twitter, GitHub, Website

Nikita Sobolev

GitHub, Website

Raquel Dou

LinkedIn 

Thank you for your continued contributions. We have added you to our Fellow roster online.

The above members help support the Python ecosystem by being phenomenal leaders, sustaining the growth of the Python scientific community, maintaining virtual Python communities, maintaining Python libraries, creating educational material, organizing Python events and conferences, starting Python communities in local regions, and overall being great mentors in our community. Each of them continues to help make Python more accessible around the world. To learn more about the new Fellow members, check out their links above.

Let's continue recognizing Pythonistas all over the world for their impact on our community. The criteria for Fellow members is available online: https://www.python.org/psf/fellows/. If you would like to nominate someone to be a PSF Fellow, please send a description of their Python accomplishments and their email address to psf-fellow at python.org. Quarter 4 nominations are currently in review. We are accepting nominations for Quarter 1 2024 through February 20, 2024.

Are you a PSF Fellow and want to help the Work Group review nominations? Contact us at psf-fellow at python.org

Announcing the Deputy Developer in Residence and the Supporting Developer in Residence

We’re very happy to welcome Petr Viktorin as the Deputy Developer in Residence! Better yet, he is joined by Serhiy Storchaka as the Supporting Developer in Residence. This transforms the residency program into a full blown team! We couldn’t be happier.

It’s exciting to be able to begin to realize the full vision of the Developers in Residence program, with special thanks to Bloomberg for making it possible for us to bring Petr on board. The initial idea behind the Developer in Residence was to have three to five people hired directly by the Python Software Foundation to help with developer efficiency at CPython, where most of the contributors are volunteers. Three to five people is a good amount to allow for handling both day-to-day tasks, as well as planning and executing on larger-scale projects.

We were only able to start with a single Developer in Residence, initially sponsored by Google for the initial year, and by Meta for the following two years. We were clear that adding more developers in residence would multiply the impact of the role but, of course, the big question is funding. Fortunately, the success of the initial one-person program allowed for a new sponsor to participate, interested in extending the program with another developer. Thank you, Bloomberg!

We announced the job opening back in July, and the interview process was extensive. The Foundation received close to 100 applications, and it was a very tough decision, as most were excellent candidates. One surprise in particular was that despite the Deputy role being described as targeting programmers of various experience levels, we received many more applications from Python core developers than during the initial Developer in Residence job opening.

Naturally, the core developers bubbled up in the interview process. We were especially impressed by Petr Viktorin’s experience with maintaining Python at Red Hat, his interest in the C API, and his long-term existing contributions to Python. Given the transformative recent developments inside the interpreter in terms of performance and scalability, Petr’s skillset was the perfect match. We’re excited he accepted the offer!

However, there was one more person who we were also ready to hire on the spot: Serhiy Storchaka, a rare example of a core developer generalist, with plenty of C experience and contributions across the entire codebase. Consistently one of the top most prolific contributors to Python, we felt like we needed to secure him as a member for the Residents team. Unexpectedly, a generous anonymous donation allowed us to hire Serhiy as well. Thank you!

We are calling the role the Supporting Developer in Residence to make it clear the funding level here isn’t as high as in the Deputy case. Please contact us if your organization can help sponsor Serhiy to bump him to the Deputy salary. Serhiy sure deserves it!

After an initial meeting with the Steering Council, the Residents team is now ready to take on a more active role in shaping the development of the language. The Council advised that while every team member is expected to prioritize unblocking other contributors and keeping the developer experience smooth, with three people on the team each Resident can now also spend a percentage of their time on feature work aligned with their interests.

There are some exciting times ahead for Python!

EU’s Cyber Resilience Act Passes with Wins for Open Source

Back in April, we wrote to the community about our concerns for the future of the open source ecosystem generally and CPython and PyPI specifically if the European Cyber Resilience Act (CRA) were to pass in the form that had been shared. At the time, we were worried that in the course of providing software for anyone to use, analyze or change that the PSF and/or the Python community might become legally responsible for security issues in the products that are built with the code components that we are providing for free. We asked for increased clarity, specifically:

“Language that specifically exempts public software repositories that are offered as a public good for the purpose of facilitating collaboration would make things much clearer. We'd also like to see our community, especially the hobbyists, individuals and other under-resourced entities who host packages on free public repositories like PyPI be exempt.”

The good news is that CRA text* changed a lot between the time the open source community – including the PSF – started expressing our concerns and the Act’s final text which was cemented on December 1st. That text introduces the idea of an “open source steward.”

“'open-source software steward’ means any legal person, other than a manufacturer, which has the purpose or objective to systematically provide support on a sustained basis for the development of specific products with digital elements qualifying as free and open-source software that are intended for commercial activities, and ensures the viability of those products;” (p. 76)

Furthermore, the final text demonstrates a crisper understanding of how open source software works and the value it provides to the overall ecosystem of software development.

“More specifically, for the purpose of this Regulation and in relation to the economic operators referred therein, to ensure that there is a clear distinction between the development and the supply phases, the provision of free and open-source software products with digital elements that are not monetised by their manufacturers is not considered a commercial activity.” (p. 10)

So are we totally done paying attention to European legislation? Ah, while it would be nice for the Python community to be able to cross a few things off our to-do list, that’s not quite how it works. Firstly, the concept of an “open source steward” is a brand new idea in European law. So, we will be monitoring the conversation as this new concept is implemented or interacts with other bits of European law to make sure that the understanding continues to reflect the intent and the realities of open source development. Secondly, there are some other pieces of legislation in the works that may also impact the Python ecosystem so we will be watching the Product Liability Directive and keeping up with the discussion around standard-essential patents to make sure that the effects on Python and open source development are intentional (and hopefully benevolent, or at least benign.) 

Thank you to Open Forum Europe (OFE) — especially Ciarán O’Riordan – for bringing the FOSS community together to share our thoughts on how the proposed text would affect open source, thinking about how the goals of the proposed act might be achieved without unintentionally creating a chilling effect for open source and communicating those ideas to legislators. OFE’s work to coordinate our efforts certainly made it easier for the PSF’s concerns to be heard and I’m fairly certain it made it easier for legislators to assess and consider impacts to the open source ecosystem when we were able to speak with one voice. 

*The entire Regulation is published here, if you want to dive into the text more deeply.