Mailman 3 - PyPA-Committers

Foresight integration with pypa github
by Matt Davis 20 Oct '22

20 Oct '22

Oz and myself (pipenv maintainers) have been in communications with Thundra/Foresight to test out their CI integration which is free for open source projects. According to Serkan, their CTO, "As far as we can see, the pypa organization has installed the Foresight Github app successfully and has given access to pipenv repository." However there is no foresight pypa account yet so we aren't able to complete the integration. I see two options to proceed -- Option 1 is that one of the existing pypa Github org admins will create a Foresight account for the pypa community and invite myself and Oz to the project. Option 2 is that Oz and I are willing to be Foresight admins for pypa in which case Foresight would link to one of our accounts and we would manage adding any additional users needed over time. In either case, we would work with Foresight to get a custom sub domain that is read-only so anyone in the community can view the insights provided (Example: https://mathjs.app.runforesight.com/repositories). Please let us know how we could proceed. Thanks, Matt Davis (*Sorry for the double send to the list -- I forgot to add a subject the first time and it was held for approval.)

2 1

VOTE - Accept pip-audit and gh-action-pip-audit into the PyPA
by Dustin Ingram 23 Sep '22

23 Sep '22

I'd like to propose the transfer of the following projects to the PyPA org: - https://github.com/trailofbits/pip-audit/ - https://github.com/trailofbits/gh-action-pip-audit/ More background for these projects and the long-term plan for them is here: https://discuss.python.org/t/towards-a-pip-audit-subcommand-for-vulnerabili…. We are still hoping to more closely integrate pip-audit with pip, but for now, the PyPA is a much more appropriate home for these projects, and will join https://github.com/pypa/advisory-database, which they use. This would add two existing maintainers of these projects (William Woodruff and Alex Cameron) as PyPA committers, in addition to myself. Per PEP 609: > The proposal will be put to a vote on the PyPA-Committers mailing list, over a 7-day period. Each PyPA committer can vote once, and can choose one of +1 and -1. If at least two thirds of recorded votes are +1, then the vote succeeds.

19 19

VOTE: pipenv Tidelift revenue assignment
by Oz Tiram 07 Sep '22

07 Sep '22

Dear Pypa Committers, I am writing to you to ask for your vote on the following resolution: Please approve remitting pipenv Tidelift revenue net of Python Software Foundation's administrative fee to the pipenv page maintainer, Frost Ming from March 2021 to December 2021 and 50/50 to Oz Tiram and Matt Davis from January 2022 on until such time as the maintainer(s) changes. The PyPA will share the voting results of this resolution with Python Software Foundation. In case you have not noticed, after a long hiatus where pipenv wasn't maintained at all or solely maintained, the project is now live and active. We (GitHub handles @oz123, @matteius) have been fixing bugs, removing old code, answering questions and released multiple versions of pipenv in the last year. Although there are other tools that help Python users to manage their virtualenvs, pipenv remains used by many members of the community. We know this since there are many new contributors and bug reports in the period since we adopted this project from @frostming. On behalf of Matt Davis and me, Best regards Oz Tiram

10 13

VOTE: virtualenv Tidelift revenue assignment
by Bernat Gabor 03 Sep '22

03 Sep '22

I'm calling a vote for: The PyPA approves remitting virtualenv Tidelift revenue net of Python Software Foundation's administrative fee to the virtualenv project maintainer, Bernat Gabor, from March 2021 on until such time as the maintainer(s) changes. The PyPA will share the voting results of this resolution with the Python Software Foundation. Thanks, Bernat

10 10

Fundable Packaging Improvements
by Shamika Mohanan 24 Jun '22

24 Jun '22

Hello, The Packaging Working Group <https://wiki.python.org/psf/PackagingWG> maintains a list of Packaging tool improvements <https://github.com/psf/fundable-packaging-improvements> that are looking for funding. This list has not been updated recently and is tilted towards PyPI. We are looking to update this list with new ideas. If you have an idea that is fairly popular within the community and can be delivered quickly with funding, please submit a PR. This list is open to ideas from all packaging tools. If you need help scoping an idea, please get in touch with me. Regards, Shamika

1 0

Moving the PyPA to use the PSF's CoC reporting procedures
by Dustin Ingram 23 Jun '22

23 Jun '22

In PEP 609 <https://peps.python.org/pep-0609/>, we moved the PyPA to use the PSF's Code of Conduct, but we left in place a PyPA-specific CoC team <https://github.com/pypa/.github/blob/main/CODE_OF_CONDUCT.md>. I'd like to propose moving our reporting procedure to use the same procedure as the rest of the PSF <https://www.python.org/psf/conduct/>. Practically this means that we'd dreprecate the conduct(a)pypa.io alias and reports would go right to conduct-wg(a)python.org instead. A few advantages: - The PyPA is not a 'special case' for PSF projects when it comes to CoCs - The CoC team would include unbiased members that aren't part of the PyPA - Better response time, and more experience around response procedure, etc. Given that PEP 609 doesn't actually talk about the conduct(a)pypa.io intermediary, this might not be considered an "Update to the Governance/Specification Processes" <https://peps.python.org/pep-0609/#updates-to-the-governance-specification-p…>, but I'd like to propose a vote on this anyway. Reminder that a PyPA committer vote is triggered when a PyPA committer (not the proposer) seconds the proposal. Thanks!

16 21

Fwd: Important information about your GitHub account
by Dustin Ingram 17 Jun '22

17 Jun '22

Please see the notice below. Can someone confirm that the following scoped installation tokens are legitimate? ---------- Forwarded message --------- From: GitHub Security <no-reply(a)github.com> Date: Thu, Jun 16, 2022, 2:26 PM Subject: Important information about your GitHub account To: Dustin Ingram <dustin.ingram(a)gmail.com> Hi di, We're writing to let you know that between 2022-02-25 18:28 UTC and 2022-03-02 20:47 UTC, due to a bug, GitHub Apps were able to generate new scoped installation tokens with elevated permissions. You are an owner of an organization on GitHub with GitHub Apps installed that generated at least one new token during this time period. While we do not have evidence that this bug was maliciously exploited, with our available data, we are not able to determine if a token was generated with elevated permissions. User privacy and security are essential for maintaining trust, and we want to remain as transparent as possible about events like these. GitHub itself did not experience a compromise or data breach that either created or resulted from this event. Read on for more information. * What happened? * GitHub learned via a customer support ticket that GitHub Apps were able to generate scoped installation tokens with elevated permissions. Each of these tokens are valid for up to 1 hour. GitHub quickly fixed the issue and established that this bug was recently introduced, existing for approximately 5 days between 2022-02-25 18:28 UTC and 2022-03-02 20:47 UTC. GitHub Apps generate scoped installation tokens based on the scopes and permissions granted when the GitHub App is installed into a user account or organization. For example, if a GitHub App requests and is granted read permission to issues during installation, the scoped installation token the App generates to function would have `issues:read` permission. This bug would potentially allow the above installation to generate a token with `issues:write`, an elevation of permission from the granted `issues:read` permission. The bug did not allow a GitHub App to generate a token with additional scopes that were not already granted, such as `discussions:read` in the above example. The bug did not allow a GitHub App to access any repositories that the App did not already have access to. In order to exploit this bug, the GitHub App author would need to modify their app's code to request elevated permissions on generated tokens. * What information was involved? * The following GitHub Apps generated scoped installation tokens during the bug window for your organization(s). We are not able to determine if a token was generated with elevated permissions. Organization: GitHub Apps pypa: OpenDev Zuul, Azure Pipelines, No Response * What GitHub is doing * GitHub immediately began working to fix the bug and started an investigation into the potential impact. However due to the scale and complexity of GitHub Apps and their short-lived tokens, we were unable to determine whether this bug was ever exploited. We are notifying all organization and user account owners that had GitHub Apps installed and had a scoped installation token generated during the bug window so that they can stay informed and perform their own audit of their installed GitHub Apps. As a followup to this investigation, GitHub is looking at ways to improve our logging to enable more in-depth analysis on scoped token generation and GitHub App permissions in the future. * What was the potential impact? * Due to the variety of GitHub Apps, their possible scopes, and the repositories they may have been given access to, we are unable to advise on any potential impacts as each customer's situation will be unique. * What you can do * While we have updated our systems to resolve this bug and no action is required on your end, we do recommend you review your installed GitHub Apps. You can use the following guidance for assessing GitHub Apps, their permissions, and their access to your private organization repositories: https://docs.github.com/en/organizations/keeping-your-organization-secure Please feel free to reach out to us with any additional questions or concerns through the following contact form: https://github.com/contact?form%5Bsubject%5D=Re:Reference+GH-0003281-4728-1…. Thanks, GitHub Security <Reference # GH-0003281-4728-1>

1 0

Vote to adopt extensionlib
by Ofek Lev 15 Jun '22

15 Jun '22

https://github.com/ofek/extensionlib is the library based on https://hackmd.io/@gaborbernat/py-packaging-summit-2022#Building-C-Extensio… The goal is to iterate on it while implementing a PoC for an existing project like Mypyc or Cython, then write the PEP to standardize the extension module builder interface, registration, and configuration. I'll start the vote with an explicit +1

8 11

Feedback requested re: PEP 621 and packaging tutorial
by Brian Rutledge 31 May '22

31 May '22

I've started a discussion on the packaging forum about dropping `setup.cfg`/`setup.py` in favor of `pyproject.toml`, and would appreciate thoughts from this group. https://discuss.python.org/t/removing-setup-cfg-and-setup-py-from-the-packa…

1 0

Vote on adopting the hatch project under pypa
by Bernat Gabor 11 May '22

11 May '22

Hatch 1.0 has been released - see https://discuss.python.org/t/hatch-1-0-0-is-available/15359 The project has a test environment management side, but also a build backend under the hatchling name. The source repository is at https://github.com/ofek/hatch. I'll start the vote with +1 to it (I only used the hatchling side of it, but that works great and supports all packaging PEPs adopted, so it's a good replacement to setuptools), Bernat

12 15