[woodruffw]

That’s now how any of this works. I am begging you to re-read the docs and understand that this does not require anybody to use GitHub, much less GitHub Actions, much less Trusted Publishing, much less attestations.

You can still, and will always be able to use API tokens.

[lucideer]

> I am begging you to re-read the docs

The gp was pointing out that the docs heavily emphasise (& therefore encourage) GHA usage & suggested language changes.

If people are confused about what they need to use Trusted Publishing & you're suggesting (begging) a re-read as the solution, that seems evidence enough that the gp is correct about the docs needing a reword.

[nmstoker]

It could just as easily imply that people aren't paying attention when they read it. Inability to understand a text is not always on the author, plenty of times it's on the reader.

[st3fan]

Well, yes and no. From the perspective of an infosec professional who is focussed on supply chain security I can tell you that your package having an attestation from a trusted platform like GitHub or GitLab gives me a warm feeling. It is not the only thing we will look at but definitely part of a longer list of checks to understand risk around dependencies.

With an attestation from GitHub I know at least that the workflow that ran it and the artifacts it produced will be 100% traceable and verifyable. This doesn't mean the code was not malicious, but for example it will rule out that someone did the build at home and attached an alternative version of an artifact to a GitHub release. Like how that was done with the xz project.

It is fine to not like GitHub, but I think that means we need more trusted builders. Developers cannot be pushed toward just GitHub.

[woodruffw]

> It is fine to not like GitHub, but I think that means we need more trusted builders. Developers cannot be pushed toward just GitHub.

Yes, agreed. This is why the docs explicitly say that we’re planning on enabling support for other publisher providers, like GitLab.

[ziddoap]

Thank you for being patient with people that seem to have willfully not read any of the docs or your clarifying comments here, are saying you are lying, and/or are making up hypothetical situations. It's appreciated!

Edit: woodruffw is sitting here and thoughtfully commenting and answering people despite how hostile some of the comments are (someone even said "This is probably deserving a criminal investigation"! and it has more upvotes than this comment). I think that should be appreciated, even if you don't like Python.

[HelloNurse]

I know attestations are not mandatory, but the rug has already been pulled: PEP 740 distinguishes "good" and "bad" packages and "good" packages require GitHub.

[cpburns2009]

Attestations are worthless unless they're checked. I have no doubt they'll eventually become the default in pip which effectively makes them mandatory for 99% of people not willing to jump through the hoops of installing an unattested package.

[HelloNurse]

The "hoops", which will only increase in the future, make GitHub-dependent attested packages privileged and give GitHub (and maybe, in the future, other inappropriate entities) significant power over open source Python packages.

[woodruffw]

It does nothing of the sort, and the current GitHub requirement is an explicitly temporary restriction, like it was for Trusted Publishing. Again: I am begging you to read the docs that we’ve compiled for this.

[lucideer]

> the current GitHub requirement is an explicitly temporary restriction

It seems reasonable to suggest that advertising a solution for public use at a point in time when support is at <2 systems is not an ideal way to encourage an open ecosystem.

[woodruffw]

It’s an eminently ideal way, given that the overwhelming majority of Python packages come from GitHub. It would be unreasonable to withhold an optional feature just because that optional feature is not universal yet.

Again, I need people to let this sink in: Trusted Publishing is not tied to GitHub. You can use Trusted Publishing with GitLab, and other providers too. You are not required to produce attestations, even if you use Trusted Publishing. Existing GitLab workflows that do Trusted Publishing are not changed or broken in any way by this feature, and will be given attestation support in the near future. This is all documented.

[lucideer]

> It would be unreasonable to withhold an optional feature just because that optional feature is not universal yet.

The "reasonability" of this is dependent on your goals. If an open ecosystem isn't a priority, then your statement is indeed correct.

[HelloNurse]

Let this sink in: a "security" feature that depends on Trusted Publishing providers puts the developer at the mercy of a small set of Trusted Publishing providers, and for most people none of them are acceptable feudal lords.

Let this sink in: if it is possible to check attestations, attestations will be checked and required by users, and PyPI packages without them will be used less. Whether PyPI requires attestations is unimportant.

[ziddoap]

This is exactly what I meant when I said "people that seem to have willfully not read any of the docs or your clarifying comments here"

[ljdgah]

Since roughly 2014 there have been so many rug pulls in the Python organization that no one believes anything any more.

It always starts small: "Oh, we just want everyone to be nice, so we have this super nice CoC document. Anyone who distrusts us is malicious."

Ten years later you have a corporate-backed inner circle that abuses the CoC to silence people, extend their power and earning potential and resort to defamation and libel.

It is possible that the people here who defend this corporate attestation-of-provenance-preferably-on-our-infrastructure scheme think that nothing nefarious will happen in the future. Well, given the repressive history of Python they are naive then.

It just takes pip to add a flag to enable "non-attested" packages. And of course they'll name it something like --allow-insecure-potentially-malicious.