Fine-Grained PAT Approvals and Release Automation in PyPA Projects

Packaging
21

Yea, but knowing who the owners are is only relevant for pypa members :wink: If a pypa member can see the owners, then they have a list of who they can go bug to get something done.

That doesn’t solve the larger issues around it, but just calling it out as a stop gap!

22

Knowing the owners is often not enough. I did got the reply from some owners, look I agree, but I don’t feel comfortable me alone deciding… So here we are. Does anyone of the owners feels like they have the authority to make executive decisions? Do we need an owners list that vote?

23

Maybe the problem with your specific case is real? You are asking for your personal access token to be added to the PyPA org, just so that you can do virtualenv releases - is that right? What exposure does having the PAT at org level result in?

  • If your account is compromised, will the attacker be able to use the PAT to access other PyPA projects?[1]
  • If another PyPA member’s account was compromised, would the attacker be able to use your PAT as a result?

The principle of least privilege says that the PAT should only be available to the project(s) that need it. If the way github works makes it impossible to achieve that, we need to know the impact of that.

  1. I am assuming you’ve accepted the risk that it would expose access to virtualenv ↩︎

24

Maybe posting the request here is sufficient for that? Get a consensus here, then one of the owners can approve, knowing they are simply implementing the consensus.

25

This is wrong. I have two immediate problems:

  • adding a virtualenv only repository fine grained access token be added to the virtualenv project only (would not impact at all any other projects). The way PyPA is configured today is not right, because you need to be owner to do this, oddly enough adding an unscopped access token is allowed… (is scoped to the release pipeline only so shouldn’t leak, and either way would only be valid for operations on pypa/virtulenv)
  • installing Readthedocs GittHub App.

Neither of these feel to controversial, but without lack of clear ownership/process seems is kinda no ones responsability to help with these.

1 Like
26

Many projects use ReadTheDocs (I know pip does). What are you doing differently that needs the app adding, when other projects don’t?

(Just to be clear, I’m asking these questions because they are the sort of thing that makes me, personally, reluctant to “just approve” the requests. So they hopefully serve as examples of why things maybe aren’t as non-controversaial as they first seem.)

27

FWIW, I just got another notification:

The GitHub App psf-cabotage.us-east-2 is requesting additional access to your organization.

I have literally no idea what this means, or even what psf-cabotage.us-east-2 is (a PSF app? some malware masquerading as a PSF app?). I didn’t approve it, although it looks like someone else might have.

IMO if the pypa organisation owners are expected to approve requests that they don’t understand, like this one, that suggests we don’t have the right people as owners, or we don’t have the right organisational or process structures in place to allow the owners to do their jobs.

So on consideration, I’m now +1 on changing something to make all of this work better. I don’t know what, though :slightly_frowning_face:

28

re(specifically around cabotage): This is the platform that handles deployments for PyPI, Python.org, and other resources.

We were adding features that required additional scope for Cabotage.

I believe myself or Ee could’ve approved this, but we just didn’t get to it in time.

29

I’m not sure if you followed but recently read the docs no longer recommend using webhooks as most projects do but instead they recommend doing the integration to their GitHub application. I was trying to do this migration for the project I maintain. I’m unsure if they plan to remove the hook support or if they just discourage it, or if the hook version will not have the latest fancy features of it. Either way, the recommendation is to not use it anymore.

2 Likes
30

I’ve accepted the RtD app install, and removed the need for admin approval for PATs.

Do note that Github does not let me not have a time limit, so I’ve set it to the highest value listed (366 days).

31

what does the pypa GitHub organisation give us here? Do we even need it?

beside awareness that was already mentioned, the `pypa` GitHub organisation has specific GitHub Actions limits which would need to be re-negotiated on a project per project basis - if need be - if projects got split up into different orgs.

In the past, this also allowed to get a single PSF sponsored Travis CI subscription to work across multiple projects under the `pypa` GitHub organisation.

2 Likes
32

i don’t really have a dog in this fight per-se but personally am often confused by the pypa as an entity. i don’t have a strong opinion on the specific solution here, but I do think this thread highlights a deeper issue: PyPA effectively holds a lot of critical packaging infrastructure, yet the governance of the GitHub organization is fairly informal and, at times, unclear.

given that, it seems reasonable to at least consider whether some of this should live under the Python enterprise on Github (composed of the python, psf, pycon, and pypi organizations at the moment) where there are clearer ownership and decision-making structures. the current setup appears to introduce avoidable operational bottlenecks.

again, just a thought (and my personal opinions, not the psfs :slight_smile:)

re: the gh actions limits - in the Python enterprise any organization has a greater limit that could apply to any org (and repo) under that umbrella.

GitHub Actions billing - GitHub Docs has the GHE Cloud limits listed

33

The PyPA org on GitHub is already on Enterprise:

1 Like