Use an API token for uploading to PyPI from Travis CI instead of account creds

[webknjaz]

It is now possible to create an API token at https://pypi.org/manage/account/token/. Travis CI autoreleases should switch to that.

❓ I'm submitting a ...

• 🐣 infra improvement

❓ Do you want to request a feature or report a bug?

N/A

❓ What is the current behavior?

Account creds used.

💡 If the current behavior is a bug, please provide the steps to reproduce and if possible a screenshots and logs of the problem. If you can, show us your code.

N/A

💡 What is the expected behavior?

Token auth used for uploading to PyPI.

❓ What is the motivation / use case for changing the behavior?

Security

📋 Please tell us about your environment:

N/A

📋 Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, e.g. stackoverflow, gitter, etc.)

Ref: https://discuss.python.org/t/pypi-security-work-multifactor-auth-progress-help-needed/1042/31

Use @token for a username and the token itself for a password when using Twine: pypi/warehouse#994 (comment)

[jaraco]

I tried doing this but once again ran into the data too large issue when trying to encrypt the PyPI token for a password field. That means cheroot can't use token-based auth until its travis instance gets a larger key or this project moves away from DPL or DPL provides another mechanism by which to transmit the password (travis-ci/dpl#1101).

[jaraco]

FYI, I have installed a TWINE_PASSWORD for cheroot in Travis, so if you wish to switch the release technique to the one in jaraco/skeleton, this ticket can be closed.

[webknjaz]

@jaraco I don't actually like the idea of having a global var because of the security implications, also I want this to be in the Travis' deployment provider because it looks like a good semantical fit. In the future, I'm thinking of using https://github.com/pypa/gh-action-pypi-publish in a workflow triggered by the deployment event but that'll need to wait until GitHub fixes the bug on their side preventing deployment workflows from starting.

Interestingly, I haven't hit the issue that you're describing. If you grant me access on PyPI, I could try doing this encryption myself to see if this problem affects the version of Travis CLI that I have.

[jaraco]

@webknjaz, I've added you as maintainer on cheroot and cherrypy. Please feel free to give it a try, although I suspect the issue lies with the project (as configured on Travis) and not the key (as I use a repeatable, mechanical process to upload keys).

[webknjaz]

Right. I also get this error. I suspect it's because travis-ci.org has other limits than travis-ci.com. Should we migrate there?

[jaraco]

Should we migrate to travis-ci.com?

I don't think so. That wasn't the recommendation from the Travis team. Their recommendation was to use an environment variable. As distasteful as it is to install a global variable for a single stage, I'm inclined to do it just to maintain consistency with other projects.

I don't know the full implications of migrating to .com, but if that's the right thing to do, then I'd want to do that for all projects and not just the ones that happen to be stuck on the small encryption key.

I suspect if we were just to remove and re-create the travis instance (for cheroot), it would get 4096-bit key and a PyPI key would fit in an encrypted value, so that's an option.

[jaraco]

Oh, interesting. Migrating to Travis-CI.com is the recommended action. I still don't want to do that as a manual action once per project - that would take many hours or days. If they're going to migrate projects from .org, I'd rather wait until they do it for all the projects, and in the meantime use the less-desirable global variable as recommended.

[jaraco]

I wonder if they'll retain job history when migrating from .org to .com... and if they'll retain encryption keys (which would mean that these projects would continue to fail).

[webknjaz]

@jaraco so regarding migration, I've heard that nowadays they can enable some button on your account so that you could migrate projects by yourself. Back in the day, at the very beginning, I just sent them a list of repos in aiohttp org and they did it on their side.

As for history, they don't migrate it but it's still available under .org and they link there.

And secrets won't work because .com has different encryption keys (because it's a new integration entity).

If you're okay with this, I'll email them and will handle the migration myself. Now that I have access to PyPI, I can do this.

[jaraco]

If you're okay with this, I'll email them and will handle the migration myself. Now that I have access to PyPI, I can do this.

I'd like to do it in one coordinated steps across all (most) of the projects I maintain. Basically:

• pypa/setuptools
• pypa/twine
• jaraco/*
• yougov/*

That would hit 90% of them. If you could coordinate that, that would be awesome.

[jaraco]

By the way, this issue was addressed in #226. Feel free to track/tackle migration to Travis-CI.com in a separate thread. Feel free to use jaraco/skeleton as a project in which to file the ticket and document the effort (if there's not a better forum).