let me tell you something incredibly important about the attestations / trusted publisher thing:

if you have any of your files published by a trusted publisher with attestations, then you must have all of your files published that way (in that package).

otherwise pypi determines your project may have been compromised and puts some big red warnings up like [1]. it does not try to look at "this particular source file was never part of trusted publishing" or anything like that. and, CRITICALLY, it does not send you an email or anything like that about the non-acceptable file that you just uploaded, which it REALLY should. I mean the model is, they think these uploads are malicious by an attacker. Emailing the project maintainer(s) would be pretty important! (When pypi wanted to get rid of GPG signatures, they started sending me an email for every single signature that got uploaded. so i know you guys know how to send emails).

it's also AFAICT a permanent switch. once you put a single trusted/attested file up there, your account must now do all files in this way forever (or risk big red warnings. which maybe you're OK with that).

It would all be easier to take if trusted publishers weren't limited to solely large for-profit corporations (I'm too lazy to research if they're trying to fix this).

[1] https://fosstodon.org/@zzzeek/117554513935692558

▲

woodruffw 3 hours ago | parent | next [-]

> it's also AFAICT a permanent switch. once you put a single trusted/attested file up there, your account must now do all files in this way forever (or risk big red warnings. which maybe you're OK with that).

It's not[1].

> It would all be easier to take if trusted publishers weren't limited to solely large for-profit corporations (I'm too lazy to research if they're trying to fix this).

As mentioned in several other places, we're always interested in adding more publisher providers, provided they meet our key management and notability requirements.

(This is also the easiest way to reason abductively about PyPI's goals. If PyPI's goal was to support "large for-profit corporations," we'd have dozens of publisher providers of dubious quality and community value, rather than the small subset we currently have.)

[1]: https://discuss.python.org/t/pypis-new-security-indicators-a...

▲

zzzeek 2 hours ago | parent | next [-]

> This is also the easiest way to reason abductively about PyPI's goals. If PyPI's goal was to support "large for-profit corporations," we'd have dozens of publisher providers of dubious quality and community value, rather than the small subset we currently have.)

I never claimed pypi is trying to "support large for-profit corporations". I fully understand the "large corporations as trusted publisher" thing is because this particular subset, e.g. github, gitlab, google, are widely known institutions with "good" reputations (in this area). The issue is that pypi is not, as of yet, supporting individual projects that want trusted publishing without relying on a large for-profit corporation. I'm not too put off by it but it is definitely a thing that a private for-profit host overnight becomes horrible (see e.g. bitbucket) and I have to get off that company ASAP. Having some non-profit entities here would be extremely helpful.

	▲	woodruffw 2 hours ago \| parent [-]
		> Having some non-profit entities here would be extremely helpful. I fully agree. I am hopeful that Forgejo or whatever other underlying component of Codeberg can improve its key management primitives here, which would make it very easy to argue for their inclusion as a federated party.

▲

tzlahp 3 hours ago | parent | prev [-]

You want the ones that employ core devs through Microsoft or are approved by OpenAI, which codeberg.org is not.

▲

tzlahp 3 hours ago | parent | prev [-]

This should be the top comment. PyPI as usual screws up and spreads misinformation about projects.