I agree, but that's the benefit of hindsight :-)

PyPI is simultaneously one of the oldest and most active language packaging ecosystems out there; a lot of of the things we treat as "table stakes" in terms of good security practices weren't even invented when it was first released.

The consequence of all of this is that there's a lot of ossification, and things can't be changed suddenly without (reasonably!) upsetting a lot of people who are invaluable to the community. It'd be great in terms of security if we could just force it, but that wouldn't be fair to them, to their historical expectations, etc.

Edit: I should say: I'm not a maintainer of PyPI, just someone who has contributed to it. My opinions aren't representative.

I can't tell if you're being very overly generous to folks, or if there's something I'm really not considering. Given that I've been using a Yubikey, password manager, ssh-only auth, etc for ... idk, nearly a decade?

Did it take a whole hour to learn + setup? Yes. Do I think that over time I've been more secure, and had to deal with less headaches from the repeated LastPass breaches, password leaks, compromises, etc? Oooh absolutely.

---

Sorry Python ecosystem! Sorry a package was compromised by a careless dev. Pypi? Oh what about it? Why didn't it require basic security mechanisms to upload packages downloaded by literally tens of millions of users? Oh, we couldn't inconvenience lazy devs, come on now.

I just can't with people. These things matter. Taking hard stances and making people uncomfortable sometimes IS NECESSARY.

And to be clear, I'm not trying to come for your woodruffw (or the pypi team, god knows I've seen how HN acts with forced 2FA), I'm expressing a generous frustration that there doesn't seem to be a firewall where "general dev laziness" is overridden by idk, any sense of the commons, or any basic understanding that valuable assets WILL be attacked, passwords WILL be compromised and that some "root of trust" with something I physically can hold is pretty much required these days.

LOL HN really does not like hearing inconvenient truths or truths that point out their blind/lazy spots.

Have you considered that perhaps you are the lazy one?

You don't want to inspect the source code yourself for security holes, you don't want to pay someone to do it, and you don't want to establish a direct trust relationship (personal or legal) with the original developers.

Instead, you want to trust automation and externalize blame.

And you call others lazy?

> ... any sense of the commons

If you have any sense of the commons beyond past Hardin's simplistic and historically flawed argument advocating mandatory population control, then surely you can understand how PyPI admins are trying to balance the traditional commons use rights based on cooperation and responsibility with the needs of lazy people like you, while hopefully avoiding any devastating effects akin to how English land enclosure deprived commoners of their rights of access and privilege.

There's nothing hard about it.

This doesn't have anything to do with auditing source, that's such a creative cop out, subject change, whataboutism.

No, actually, I'm not a giant corp, I can't afford to hire teams to review every commit. Especially across the python ecosystem, it being what it is. And that's assuming it's even easy to find the damn source, or go from papi back to the actual source commit. Which, it often isn't!

Oh and supposedly I have to do this because devs that publish packages with millions of users are too lazy to have some actual security around their release process?

No. Sorry, it's not unreasonable to review a project, skim the source, and determine there's software engineering going on. However, without 2FA, none of that really matters, does it? Oh! And, this whole scenario is moot given that most people aren't pinning with hashes anyway, so your little made-up scenario and words you've effectively put in my mouth really doesn't make the point you think it does, anyway! In fact, thanks for another great point to add to my initial list!

> you don't want to establish a direct trust relationship (personal or legal) with the original developers.

Do you actually understand what this thread is even about? What in the hell good does that do me when their laptop gets swiped at a conference and their latest package gets replaced?

> while hopefully avoiding any devastating effects akin to how English land enclosure deprived commoners of their rights of access and privilege.

Wow, I can't believe I wasted my time reading you post, let alone replying to any of it. I love a dramatic flair but that's in poor taste.

Because there's a long history of people using cooperation and responsibility in PyPI, and don't have your pressing need to change. Not because they are lazy, but because they don't care about your personal needs.

Some only upgrade every few years. For me, it seems like the PyPI upload process changes faster than my release cycle.

Somehow you you think that long tail of distributors - not "packages with millions of users" because they had to switch to 2FA a couple years ago, but packages with perhaps 50 users - will jump to 2FA within a couple of years?

Calling them lazy certainly doesn't help encourage transition.

> I'm not a giant corp

So you entered the Python ecosystem without knowing fully how it works (understandable), didn't find that it meets your requirements (understandable) and decided to place the blame squarely on other people. By calling them out as "lazy."

Thing is, "lazy" can be turned around on you too.

Sounds like you were too lazy to figure out the problems with Python before you got stuck with it. You should have researched it first - then you could have gone to some other language.

Of course, the real issue is that you learned things over time, and it's hard to switch at this point.

Just like PyPI.

> too lazy to have some actual security around their release process

If they haven't updated in 4 years, what's the difference to you? You really think everyone is releasing all their packages all the time, and as on the ball as you are?

> back to the actual source commit. Which, it often isn't!

What arrogant presumption! It's free software. You paid nothing, so you're already getting more than you paid for. While at the same time you are making money from their work.

Your attitude, repeated over and over, is causing open source project maintainers to burn-out.

You want that? You pay for it, or pay someone else to do it for you, or do it yourself.

I don't develop open source now because of the attitude of people like you.

> but that's in poor taste

To strong contrary. PyPI devs must balance between the needs of corporate and professional users like you, and student and hobbyist programmers who don't care about "real security" but have something they want to publish, and only touch every few years.

Make the barrier too high, and they drop out, just like the enclosure laws to the actually-well-managed commons in England.

Sure, perhaps you want a market floor meant only for corporate and professional accounts. But I know that's not what the PyPI devs want because I've heard them talk about it.

Make the barrier too high, and people will migrate to alternate providers. It's easy to set up a 'simple' PyPI server - I have a static one for my software releases since I'm tired of dealing with PyPI changes when I just want to update via rsync/ssh.

But you know what? Pip and other programs do a really bad job of isolating packages between multiple servers. I can see pip checking my server for "pip" updates, and I can see someone tried to install "numpy" from my server. I could easily have given them a fake one.

The PyPI devs can't easily change how that protocol works, plus namespace conflicts become even worse with multiple providers, so they really do not want to encourage a migration to other systems.

Move to another programming language with a distribution security model that meets your high standards. Don't stay with Python - you'll be hating it for your entire career.