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
The extra burden I would assume discourages 99.9% of cases, similar to CAPTCHA.
Internet is full of python tutorials that create packages on pypi to teach how to do that. I expect that hundreds of people every day create completely useless packages that contain an hello world.
And certainly automating the process via copy-pastable github automations will not decrease the number of useless packages created.
Well there was never any support for creating empty projects
really. The only way to create a project was always to create a
release.
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
anything.
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
compromised already.
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.
My projects don’t exist solely on pypi. The fact that pypi no longer wants signatures is not so relevant. They are also part of distributions, which do check signatures.
Can we agree that it’s >0? And any number that is not 0 is too much?
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.
Not really… You need a global token to create a project, and then you need to do an upload, and then you delete the global token and create a token for that project.
Or you use some thing that only works on github, and has the side effect of rendering an eventual signature meaningless.
The end result of the decision is that global tokens are needed and signatures are discouraged. More inconvenience for less security…
That’s still an assumption. Do you make similar assumptions about every other organization out there, commercial and noncommercial, or are you singling out GitHub/Microsoft for this?
So how do you handle this everywhere else? And how do you handle the possibility that your computer’s OS and BIOS might be giving access to people other than you?
How paranoid are you and to what extent is it realistic?
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.
This doesn’t look like a genuine effort to understand, it’s more of an effort to dismiss my concerns labelling me as a paranoid who fears microsoft for no reason.
