Then I would not claim that the issue with needing the global token is solved.
The way I do releases is by using twine, and it loads a .txt file I have locally with the per-project token.
I also sign the release, upload it to github and to debian.
Certainly my private gpg key is not going to go on github, and without that my signature of the release is not valid, and upload on debian needs a signed .changes file, so github automations have nothing in common with how I do releases, and by design will never have anything in common since then I would be unable to sign anything.
I think that to call it resolved, it must work also for those people who sign things. I know pip doesn’t check, but debian does
Well there was never any support for creating empty projects
really. The only way to create a project was always to create a
Previously you had two options, you could use register to create
a metadata only release, or upload to upload an artifact and
create a release. We dropped the register command, requiring an
artifact to be uploaded to create a new release.
Right, and at one point Cheeseshop also had a web form which could
be used to trivially register a project, though presumably it was
just another way of accessing the register function of what amounted
to the Cheeseshop API at the time. By “empty” I meant none of the
releases had corresponding files, but there was still metadata sure.
Certainly my private gpg key is not going to go on github, and
without that my signature of the release is not valid, and upload
on debian needs a signed .changes file, so github automations have
nothing in common with how I do releases, and by design will never
have anything in common since then I would be unable to sign
One way some people tackle this is to generate a signing-only
subkey, so that its signatures still chain up to your primary key
but it can be revoked independently in the case of compromise.
Being on a machine which I don’t control counts as being
Said artifacts are being compiled on that machine you don’t control,
so are also compromised already, correct? Why would you sign them at
all? If your answer is “reproducible builds” then you’re building
them locally too in order to make sure the hash matches, so why
upload from automation in the first place? Just sign and upload the
version you built on the machine you trust.
Signatures don’t prove the system where those artifacts were built
wasn’t compromised; signatures (at best) provide proof of provenance
so you can try to confirm that what they signed was built or
validated by a system which had access to the signing key.
They don’t prove my machine wasn’t compromised, but the moment I put my private key on github, possibly thousands or tens of thousands of microsoft employees will have access to that, so it wouldn’t prove provenance at all.
And now with talk of EU introducing legal responsibility, letting an unknown amount of people impersonate me doesn’t seem such a bright idea.
PyPI doesn’t support GPG signatures, so I’m not sure that what you do or don’t do with GPG is particularly relevant for PyPI.
I also suspect that tens of thousands of Microsoft employees do not have access to secrets on GitHub, that just sounds like FUD, though I agree putting a GPG private key on GitHub isn’t particularly a good idea (though I don’t think owning a GPG key is a good idea in general).
If you want to upload things to PyPI without creating a global token, you can use project scoped tokens.
If you want to create a brand new pacakge without creating a global token, that’s not currently possible without trusted publishing, which will almost certainly never support “random engineers laptop”, currently only supports Github but will support other platforms in the future.
I’m sorry, what does OT mean here? Do you mean off-topic?
I don’t view the questions asked as being off-topic, since asking for details on what your trust model is very much relevant, given that you are describing the lack of trust in existing mechanisms provided to prove provenance.
Additionally, please don’t respond to a question with a rhetorical question. It is not constructive form of discussion in any forum, let alone a text-based one.