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
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!
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>