On 2023-11-17 01:55:45 +0100 (+0100), Salvo Tomaselli wrote: > You have a system that is an insane overkill. I'm one guy with one > computer and no funding to do any of this.
I admitted as much. My point was that building, signing, and
uploading the tarball to PyPI are distinct steps which can be
performed separately in different places. You were arguing that if
you wanted to use GitHub Actions to authenticate your uploads to
PyPI then that necessitated putting your private OpenPGP key there
too, and I was trying to demonstrate that your assertion is patently
false. Build/sign in one place, upload from another (like GitHub
Actions in this case). That totally works. It also seems like common
sense, so I get the feeling I'm not understanding your actual
complaint.
> The maintainer of pypi stated that the issue of the global token
> being needed is fixed. But it is fixed IIF you upload via github's
> CI.
>
> But I want to sign things and I want the pypi thing to be
> identical to the one that I sign.
Build and sign it, then hand what you built off to your uploading
system. Why wouldn't it be the same? PyPI also reports a strong
checksum for each uploaded file, so if you don't want to download it
again to double-check, you could just compare that to the checksum
of the local file that you signed.
> So some other user suggested that I should upload an easy to
> revoke key and use that one to sign.
If you're talking about the discussion on the Python Discourse, I
think that was me. I remember pointing out that some people who *do*
choose to perform OpenPGP signing of artifacts in build automation
like CI/CD systems do so with a signing subkey in order to not give
their primary private key to that automated system. This really has
nothing to do with how you upload files to PyPI though, so I
continue not to understand what your actual complaint is.
> In the end pypi's security got worse because I used to type in my
> password to upload, while now I am forced to keep it in a plain
> text .txt file for twine to be able to read it.
You should be able to interactively enter the upload token too, it's
really just a password with a common username ("__token__"). You
have to prefix the token string with "pypi-" though when entering it
like a password. See the PyPI help page for details:
https://pypi.org/help/#apitoken
I haven't tested doing that with Twine specifically, but it ought to
just work.
> This is because one of my project is "essential" or whatever. So I
> must use the 2 factor authentication, which is actually needed
> only once, to create a global token and then can be ignored
> forever.
I do disagree with how they forced 2FA on a subset of maintainers
based on some arbitrary metric, and then tied required use of
separate upload tokens to that, but since I don't help to run the
service it's ultimately not my call.
> I personally actually revoke the global token every time, and
> create a new per-project one. But I can guarantee you that 99% of
> people in my situation are using a global token for everything.
>
> So in the effort to improve security pypi dropped signatures, and
> forces people to keep the password in a .txt file.
As I mentioned above, you're not required to store the token in a
file unless you want to be able to use it non-interactively. But I
agree, most people probably are just sticking it in a file. To be
fair though, most people did that with the old username/password
system for PyPI uploads too, I expect.
> Personally I think security was not improved, and seems that the
> maintainers of pypi don't even realise. But that's my perception.
It's a step up from when non-interactive use required you to put
your PyPI account password in a file. At least upload tokens only
have the ability to upload new versions of your projects, they're
scoped to disallow anything else. Having 2FA to log into the account
in order to get access to the other functions is arguably a little
more secure than before too.
But yes, they have made things more complicated and more
inconvenient, which often ends up pressuring users into finding
less-secure workarounds, defeating the purpose of the additional
measures they enacted.
--
Jeremy Stanley
signature.asc
Description: PGP signature
