# Supporting Python ecosystem security

Friday, December 1 2023
15:30 - 16:00 UTC

## Attendees

[Megan Bruce]([e-mail])
[Brian Dussault]([e-mail])
[Evan Anderson]([e-mail])
[Juanita Gomez]([e-mail])
[Luke Hinds]([e-mail])
[Seth Larson]([e-mail])
[C.A.M. Gerlach]([e-mail])

## Notes

Luke: How can we help regarding security aspects in Python?
The idea is not to add more work to the ecosystem but to help.
Some considerations
- Is there enough people to work on security?
- There has been a lot of typosquating attacks.

Seth: When it comes to reporting packages when you do automating scanning, we are working on an API to enable any sort of program that scans pakcages via de API instead of email.
Long term goal: Some sort of automated way. If we have some trust scanners we should be able to get feedback on packages on PiPy. (Not sure if this covers typosquating attacks)

Evan: Something like a "strikes" program? (ducks)

Seth: It would be more agressive than that

Luke: Do you think you need more folks to help? How is your capacity?

Seth: It is a more probabilistic management situation.For example regarding SBOMs on Python packaging there is almost no one working on that. The role has a big capacity where I can be part of several efforts from different groups.

Luke: Is there any particular pain points or things that are not getting enough attention?

Seth: Sigstore project will be large because it will require multiple PEPs and a lot of folks because you need to take into account installers. So getting that working will get a big chunk of work.

Adoption of security practices and new tools.

C.A.M.: Here's a list of fundable PyPI/Python packaging improvements, though not all related to security: https://github.com/psf/fundable-packaging-improvements

Luke: How does it work for the projects that can be funded?

C.A.M.: Some things in the past got funding but didn't continue the work because there is a disconnect between the packaging community and the working group.
For the logistics side we need to talk to Deb [e-mail] on the PSF

Evan: What have you tried so far regarding adoption?

Seth: Initially there was a blogpost with trusted publishing, warnings when you don't have 2FA. When uploads are not permitted without 2FA (In January 2024) ideally people will chose to use trusted publishing.

C.A.M.: WIth 2FA, the initial strategy was to designate the top 5% of projects as critical, require them to enable 2FA but also offer to send out free security keys to those maintainers...so the carrot and the stick. Unfortunately, there was quite a bit of negative backlash in the community from maintainers

Luke: New tool https://github.com/psf/fundable-packaging-improvements/blob/master/FUNDABLES.md#productionize-malware-detection
We want to set up a partnership with virus scanning
Who in the ecosystem would we talk to? Packaging team?

Seth: It would be me or Mike who is implementing the observable malware API.

Luke: Would you be open to query another service?

Seth: We haven't consider that. We accept malware and typosquating reports via email.

Megan: CAM and Seth are finishing [PEP 639](https://peps.python.org/pep-0639/). Trusty might be useful trustypkg.dev

Seth: Deprecating the old way of doing things. There's no standard around licensing identifiers.

Evan: A particular cool example in Go, there is different licenses depending what you're using. Very messy. No way to express it with SPDX.

Megan: It makes sense to integrate that into Trusty