I understood that was where you were, and by accepting that constraint you define what you can and cannot do vis-a-vis package signing. As you point out there isn't a magic bullet, some forgotten design pattern or algorithm, or some clever slight of hand that will make your repository secure.

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.

Interestingly enough I actually I have a rough sketch of an idea which will probably get laid out in a future post. I started to add it to this one but it felt disjointed and crammed to add it so I figured I'd wait till later :)

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.

Hmm, with Ubuntu, there is not a required web-of-trust, as the uploader merely adds their key to their account using Launchpad.

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.

But Launchpad accounts only get upload rights when their prior work is reviewed by the developer membership board. And the prior work is identified against that same Launchpad account. So there is a root of trust: it's the developer membership board. It just happens that the trust system isn't implemented using a PGP web of trust directly.