I don't think this is true. From my experience, developers are the people who care about this topic the most. Just look at HN, almost everyone (who speaks out) is against.
I'm very in favor of this work, but don't generally comment because these comment threads are full of folks strawmanning the work being done, and in my experience those folks aren't really interested in productive discussion.
I'd be wary of trying to estimate the split of opinions based on who comments.
Can you explain the misconceptions? Currently what I see is a) a checkmark box that can only come from a large provider, and b) no good idea of what that checkmark box means in a practical sense, or why I should care or why pypi cared to implement it. What is the threat that this prevents? To me this seems to not particularly improve security but that it does create this pressure towards using a small subset of providers (even if that pressure is pretty light at the moment).
(I've had a quick read through the various links but they mostly seem to emphasize what it's not, which is why I say that it doesn't seem to improve security, and especially I don't really see a motivation for why these other parties need to be involved in the way they are: the only benefit I can imagine is a third-party attestation that some artifact corresponds to some source code, which seems to be partly besides the point and partly solvable through better means)
If you're curious to dig into what the checkmark means, why you should care, and why they implemented it, I'm not going to be able to do a better job than https://docs.pypi.org/attestations/security-model/
the point here being small service providers are _also_ able to get into this system, but I think there's an expectation of success.
The bar for trusted publishers is very high though. I don't think it's high "on purpose" to leave out certain platforms for being too small, but in effect if (for example) your provider doesn't have a security contact point then that's going to rule them out here.
I’d like to see support for trusted publisher signing and manual upload. Think of it as two step auth for artifact publishing. Pipeline generated artifacts and human upload of those verifiable artifacts. The current reality of trusted publishing, is devoid of trust, except it was triggered by a pipeline that pypi trusted. That pypi is now able to call out such trust is great btw, but as a project that currently does this two step generation, it feels like we are penalized for trying to introduce additional steps out of abundance of caution… separately, what mechanism does a client installer have to verify a pkg install was cryptographically attested to wrt to production?
sans client verification of signatures by default, install is still roulette, and I’m glad package managers have introduced package publication date based cool off options now.
Yeah that's not the worst idea, since in theory signing is about tamper prevention.
(Personally I think that we just shouldn't have automated releases via CI, full stop. There should "always" be a person pressing a button to release things. So I'm in a bit of a big tent with manual upload support. At least some second factor for releases!)
I think generally though the idea is that trusted publisher signing + upload is about simplifying .... something. But given how attacks have been happening in the past 24 months I fear that this might not help as much as we want.
So what? Ultimately the trust model is supposed to be there to validate that this latest blob of code is coming from the same source as the last blob of code for the same project, authenticated with the same public key. And that's all it is telling you, and all that it can tell you, whether the attestation is generated during a Github workflow or by a program running on my personal computer that you can't see. It is not telling you that this latest blob of code is safe and free from problems. It's just telling you that it comes from the same source.
The average person using GPG isn’t actually providing me much evidence in that regard, given the number of ways to have technically used a GPG key to sign an artifact that aren’t secure.
That's easy to handle: if the signature isn't secure, it doesn't count as an attestation. I have no problem with putting the onus on the person doing the signing to do it right. But at present doing it right on your own is not even an option. Only going through one of the tech giants is.
They can't. But they can't tell for sure if large tech corporations are doing that either. Data breaches are a thing. Auditing Github workflows doesn't prevent them.
The fact that a large company can mess things up doesn't change the fact that it's way more viable to review how Github or Gitlab or Codeberg handles key material and security than it is to make a comparable local developer flow that avoids common mistakes like just dropping the signing key on disk on whatever servers you want to run your builds from.
> it's way more viable to review how Github or Gitlab or Codeberg handles key material and security
Only if you already trust them.
> dropping the signing key on disk on whatever servers you want to run your builds from
I run my builds on my local machine. The private key I would use to sign them if PyPI supported that is not anywhere in the repo I'm using.
Of course you would have to trust that I'm telling the truth in what I just said. But, as above, you also need to trust what the large tech forges are telling you in order to review how they handle their keys.
1. "ClosedAI" is not gonna win people over to your side, IMHO. Apple doesn't plant trees, Microsoft makes big hardware, and Python is not satanic.
2. I'm not entirely sure what the link is supposed to prove -- would appreciate a word of clarification if you find the time. It almost feels like a dogwhistle of some kind, but A) I doubt anyone on HN is anywhere near that problematic, and B) there's no clear pattern in those companies other than "interested in ID tech", and none of the usual dogwhistle targets made the list. Also, y'know, OpenAI isn't on it...?
I guess my fundamental confusion isn't about the list and more about what "we know". Are you implying that they are against pure, unmanaged PGP for this system because... I mean, why? Because they're playing the long game to promote a verification/attestation/identification (?) technology that you think offers less stringent privacy guarantees, and thus to sell more ads in 2036?
If so, doesn't that seem like a kinda roundabout way to raise Display Ads revenue, otherwise known as "that one dying industry"?
Are... are you creating new hackernews accounts for every comment? Why?
Anyway, sorry to confuse/frustrate, I was being honest and tried to explicitly not accuse you of dogwhistling. I was making a best-effort attempt to explain my confusion, rather than just replying with "that doesn't make any sense" or something.
I guess I'll briefly elaborate just in case: "dogwhistle" above refers to a specific kind of antisemetic practice where people point at a list of companies or institutions or even just people and say something like "what do you notice?", whith the message ofc being that they're all related-to/run-by Jewish people. Again, not accusing you of that -- those people don't generally come here. But absent any other logic, I am left with confusion.
I will briefly add that this very response also doesn't help, when you very clearly imply that I am "shooting down a comment" in bad faith for some sinister purpose. It, again, comes off as conspiratorial. Why would I --a sad 30 y/o child with my real name and phone number in my bio-- be shooting this down?
I guess my overall response is that this feels like a conspiracy theory without identifying the conspiracy.
It's anti lots of things, but I don't think it's anti-Pythonic. Python is about pragmatism & empathy if it's about anything -- bitcoin and such don't factor into it. See: Astral/OpenAI, Anaconda, most of the PSF board historically being employees of big corporate users of python, NVidia's relation to the ecosystem in general, etc.
As a passionate anarchosyndicalist, I, for one, am thrilled about it. Decentralization is a tool in our toolbox for identifying and dismantling unjust hierarchies, but it is not a panacea, and can be quite damaging when taken to the extreme. See: cryptocurrency speedrunning 200y of bank regulations in 20y.
To put my trust for Python in more concrete terms: they support GitLab. As a passionate GitLab shill, I really couldn't be more impressed! It continues to shock me how infrequently the second most popular forge is acknowledged, much less supported. This shows they're not just, IDK, bowing to Microsoft's demands.
> This shows they're not just, IDK, bowing to Microsoft's demands.
Not only don't we, but I must emphasize that Microsoft did not pay for anything involving the implementation of either Trusted Publishing or attestations on PyPI. I wrote a personal blog post explaining some of my own rationale for why we prioritized GitHub and GitLab for PyPI's initial support targets, and it shouldn't be surprising to anybody who knows me that the reasons are pragmatic, not dogmatic[1].
Is "a public key that I personally upload to my PyPI account, using the credentials you already have that allow me to use that account" on the list of targets that will ever be supported?
If not--i.e., if only recognized "forges" are ever going to be supported--why not?
All absolutely reasonable. At the same time though there are a lot of roads leading to centralisation, and as they all converge it gets just a bit .. problematic.
Absolutely not claiming its not a pragmatic step, but equal-footing alternatives would be useful.
I'm no tin-foil-hat - but when a website account requires government id (like in the uk), and creating software requires signing by the website, you link all the things - is that a good outcome?
This is true, and it’s why I’m hopeful that some of the newer forges can make meaningful default posture improvements that make migration away from centralized services the dispassionate choice to a user who cares about availability and security.
Yeah but aren't we talking about PyPI, here? I love some illegal software (shoutout to Anna) but it seems like leaning on various cyber-sensitive registries to make it more available is a very small reward in exchange for a huge, tangible risk.
AnnasArchive in particular is a decent example to keep in mind, since she seems to host her own GitLab instance for opensource development. Obviously that doesn't solve this exact problem b/c self-hosted instances don't work as trusted publishers, but it speaks to what I've clumisly been trying to, here: when it comes to protecting software & speech that the government is trying to ban, making sure those people can host their own stuff and still access the minimum shared infrastructure to allow people to find and use/read it is a lot more practical than trying to build the 99%'s platforms around criminality.
Cause that's what we're talking about, here, to be clear. Criminality. Again I love some criminals and even some crimes, but the word's typical connotations seem like a pretty good reminder of what prioritizing such usecases in the mainstream can cost us.
been self hosting for so long, started with sendmail running on solaris, but now docker mailserver.
Due to a forced IP change by ISP I recently changed to having outgoing mail sent by AWS SES, using it to do the DKIM signing, so my mailserver postfix uses it as the sender, but the receiving happens on my stuff.
I think its a nice balance between self hosting and managing deliverability, but agree it doesn't count as 100% self hosted.
It runs on a hp cube server in my house, backed up frequently with restic.
International students have caused a lot of weird effects in uk universities, from people being "encouraged" ti not fail them to keep the income, to required grades being higher for local students, which is a problem in subjects where there is a limited intake, to accommodation pricing jumps, and providers targeting foreign students, meaning less choice for local students. The income has also covered up a lot of the defunding of education by the government.
I think there have been a lot of unanticipated secondary effects with the sector encouraging so many.
Uuidv7 is also not so great for preserving privacy - they give away a lot of info about when an activity happened... account id = when you signed up, order id = when you bought a thing etc etc. So, combined with where a thing happened, at a shop say, puts you at a place and specific time = loss of physical safety.
There are lots of factors that feed into this: lots of solar, batteries, more efficiency, improved insulation.
Some others: increase of heat pumps, energy poverty, reduction in industrial energy (both due to good and bad reasons)
Ultimately though, its not about how much energy per capita, its about the sources of energy, and how effectively they are used... my heat pump uses infinity more electricity than my boiler, but far more effectively uses the underlying energy source.
Information wants to be free. But other than AI slop (where the tokens have become too cheap to meter), information costs money to produce. Pay with you info or your money. It's amazing how many people just cannot come to grips with that concept.
I am so trained now, that I didn’t even read what they were asking for. Just closed the tab and came here to see if there was anything of value. Too expensive to even read their wall.
Did I get that right? Seems a bit anti-pythonic.
reply