Adding PYPI API Token - best practice

[jackiekazil]

RE: #1169
When reading this -- https://pypi.org/help/#apitoken

Right now, I manually manage deployments. When these are managed automatically, it seems to be it would be a better practice to create a pypi acct that just does this as oppose to me using my account.

Am I wrong? Is this something that I am not considering?

[rht]

I concur with the need of compartmentalizing the authority of a PyPI access token. Although, speaking of security, one drawback with using the GH Actions is that it doesn't have 2FA. Using the GH Actions may be convenient (and that we can have the PyPI to be always in sync with GH releases), but also consider that we release Mesa only a few times a year, instead of something like every 3 weeks.

[jackiekazil]

Let's consider why we release Mesa only a few times year -- it is because I am the only person able to do the release.
So, with that in mind-- Adding a PyPI token - yes or no.

-- we could add a layer of security but requiring a double approval but that might slow down the merging of PRs.
-- we create a better process for deploying -- eg more people keeping on top of prepping the release & then having a set schedule - eg 1x per month, so the act of releasing is easier? We could also add a second person to be able to do the releases.

I like the idea of automation, but also am concerned about it being a quick way to pass through a vulnerability.

[jackiekazil]

Update -- we discussed this during the dev meeting today. I am going to research if PyPI can confirm that the deployment was done by github actions as well as only accepting some by a particular user or users.

Eg --

• Was this deployment trigged by jackiekazil via github actions? Yes? Then deploy. No? Then do not deploy -- do something else.

[EwoutH]

Just add the token as secret and use the PyPI publish GitHub Action:

- name: Publish a Python distribution to PyPI
  uses: pypa/gh-action-pypi-publish@release/v1
  with:
    password: ${{ secrets.PYPI_API_TOKEN }}

[rht]

As stated earlier, that solution requires 2FA to be disabled. The additional factor for the authentication is for PyPI to recognize that the push comes from a GH Actions enabled by @jackiekazil.

[EwoutH]

As far as I know, the whole industry deploys to PyPI this way. Do we really need that 2FA?

[rht]

Yes.

[EwoutH]

Could you explain why?

Only maintainers can create tags. The workflow runs only when a tag is created. Thus only then a wheel can be uploaded.

---

I dived a bit deeper in discussions about this. The conclusion of a huge debate about this was:

2FA/multifactor auth for uploads (as in, the API token plus some second factor) as discussed in pypi/warehouse#5815 and pypi/warehouse#994 (comment): Warehouse maintainers discussed this in a recent meeting. As @moshez pypi/warehouse#994 (comment), it would be worthwhile to reflect more on the threat model -- and we would need to know what clients want (Twine is only one of them), so we aren't designing in the dark. We don't have funding for that kind of cross-platform effort in the near future. And, if there's an upload flow that includes 2FA, there are diminishing returns to multifactor with scoped tokens. Therefore, this feature isn't happening in the near future, but people are welcome to open a new issue if they'd like to discuss it further.

And also see pypi/warehouse#5815 (comment)

vidartf per pypi/warehouse#994 (comment) , although we do not plan to enable 2FA for package upload, we do plan to use API keys to better secure package upload (such as via twine).

There is some newer discussion on this, but for now, when using an API key, no 2FA is needed.

[rht]

Raised pypi/warehouse#12406.

[Corvince]

Could you explain why?

Also interested in this, what is the threat model here?

[rht]

It's the usual reason why 2FA is needed. Having the API token compromised without the 2FA enabled would allow an attacker to slip in some minor versions (they could be undetected for a while) of Mesa with malicious code, where it is done separately from the GH Actions workflow.

[rht]

You could argue that:

• Poetry is used by a lot more projects than Mesa
• It has a more fatal consequence if compromised, affecting all the projects that deploy using Poetry
• But they still use poetry publish in a GH Actions workflow anyway
• Therefore, if even Poetry feels safe about this, then we should do the same

I'm fine with this for now (until PyPI supports trusting a specific GH Actions; you can track this at pypi/warehouse#10970). Though I definitely am more wary of using Poetry now.