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.