Kind of not the main point here, but I've been in a store that was left unattended and there was a basket of money out for people to make their own change. As far as I know it's still there...
It isn't like that today, and Endicott is quite a bit larger than it was then, and people are sadly a lot less neighborly than they were when I was a kid (could be nostalgia though).
I believe the trust issue was "resolved" by locking the store when the pharmacist was out, and eventually raising prices so that they could pay the salary of someone to be there to help.
And so it is with the PyPI community, everyone is trusting everyone not to do anything bad. And that is a perfectly reasonable strategy, you just have to accept the risk that comes along with it. Sometime in the future something bad could happen if someone chooses to violate that trust.
Now in a classic vulnerability analysis you'd ask "What is the motive or payoff?" You don't put a steel vault door on your home because chances are if somebody wants into your house that badly they are going to come through the window. You accept a certain amount of risk, perhaps you have a home safe for really valuable stuff and insurance for the rest.
An organisation I am familiar with enabled "AllSigned" via group policy. For those who don't know about PowerShell, this forces every script that runs on the system to be signed with a trusted* certificate.
This immediately meant that developers had trouble using NuGet in Visual Studio (lots of packages run init.ps1 to do setup and move files around, but few are signed). You can't even accept the prompt for signed packages (Do you want to run this script signed by "Microsoft Corporation"? [Y] [N]) because the prompt isn't interactive while NuGet is installing packages.
That kind of setup also precludes the use of Choclatey or any other solution that might be using Powershell without the correct signatures.
Finally, if you can run Powershell interactively, you can still just write code or use Invoke-Expression (eval).
Wargh.
*Trusted in this case still means you'll get a prompt the first time you run the script, and a Visual Studio extension installer still runs with enough permissions to install its own certificate into the right store, so I can still be evil if I want. That's assuming the admins haven't accidentally enabled the proxy MITM certificate for code signing (I'll just export and use that instead).
That leaves you with one of two choices, accept that it isn't going to be secure and plan accordingly, or change the constraints.
For example, lets say you had exactly 1 volunteer who was willing to sign up to be your key signing authority, and as a volunteer they were only available on weekends. You could build a central authority but the throughput would be quite slow. That would impede your developers from getting authenticated and packages would take a long time to get out. But they would be signed and you would have some measure of trust in the packages as signed.
That might be unacceptable to your user base and they all go off and use something else (or as it often the case in open source they fork a new copy and decide theirs will have the rules they want). No amount of forking will create a secure system, so your constraints mean you choose risk and a wide pool of developers over less risk and fewer developers.
That a system that meets two incompatible constraints simultaneously is impossible should not necessarily stop you, but it can inform on what will happen in the possible futures. Its like growing old, you can say "I never want to be older than 25" but really there isn't anything you can do about that, what you can do is say "I always want to be able to do the following things like I was 25 ..." and work on what ever sort of preventative exercises or stuff you need to work on to make that true, but you can't stop yourself from aging.
So you can't have a package signing system with the current developer environment. Awesome, what about package signing is important going forward and what about it isn't as important? And given that, what changes can you make and what changes can't you make? And then given that you know how the future for that particular set of choices are going to roll forward.
But you're right something somewhere has to give because nothing is 100%. I hoped to show people that things aren't 100% and just slapping some crypto in there isn't going to give the results they were hoping for.
If the user was able to access their Launchpad account, there is implicit trust.
There isn't a Ubuntu shared keyring for each developer/maintainer, as there is with Debian - rather, a handful of shared keys, where the secret is only held by the infra. These are currently, Apt Archive, CD image & now Ubuntu Cloud Archive.
So in the field of package signing, you can, if you choose to, nominate a single signature authority. This is basically what Microsoft does, they are the signature authority for all keys that sign things that go into Microsoft products. When you choose a signature authority that becomes the first lemma in your calculus "I trust <foo>."[1] Now, once you have that lemma you can build on it with statements like, "I trust Microsoft, and Microsoft trusts Dell, so I will trust that the key Microsoft says is Dell's really is Dell's."
Now you've created a transitive trust relationship, in that you not only trust Microsoft's internal processes, but you trust that it will do a good job of auditing Dell's before it gives its blessing to Dell.
Now Don makes a minor error when he says, "PyPI allows anyone to sign up and make a release which makes verifying authors an unmanageable problem." the issue is that PyPI doesn't create a durable relationship between people you trust and someone you don't know.
Because of this you have to assume there are bad actors who are making packages and simply not install them. This isn't an "unmanageable problem" this is "inconvenient." (not being snarky, trying to be precise). You can run a grocery store where everyone puts the money they owe into the cash register before they leave there are no checks on the cash register, everyone is trusted to do the right thing. The store going out of business isn't a "problem" it is the expected outcome. This comes up in policy debates as well where person A wants their free speech rights but they also don't want person B to make remarks they consider to be hateful (thus impinging on person B's free speech rights). Its the 'incompatible constraints' problem.
There are a number of interesting zero knowledge proof techniques in cryptography, things which allow someone you know nothing about (zero knowledge) to prove they are a particular person, and starting from there you can create durable audit trails of actions (useful in digital cash systems among others) but it also allows you to identify bad actors, sadly after the fact, because you can make statements about the person who identified and the package they produced. You cannot say anything about motive (they may have built their package on a compromised machine) but you can trace back the action to where it entered the system, and with sufficient audit trails back it out of the system.
As you can imagine these systems are challenging to get right, challenging to build, and take an expertise that is generally highly valued so rarely available "for free."
But working on challenging problems has its own rewards and so I recommend it highly. It is always a workable approach to start with assumptions (lay them out and keep them front and center) to gain an understanding of the more challenging aspects, and then work from there. Since you aren't building life support systems you may find that just good auditing trails is enough if they allow you to back up to any previous state. Sometimes using a centralized authority gives you enough to build a system around it. I highly recommend Schneir's "Applied Cryptography" for a pretty approachable take on these topics.
[1] People will attempt to derail this example with "but I don't trust Microsoft!" or some such. Which is fine, pick an authority you do trust and use that as a place holder.