[enaeseth]

If the package repository acted as a certificate authority, and generated distributors' certificates by verifying the distributor's appropriate virtual identity (GitHub, BitBucket, DNS), then I think you can at least be pretty sure that the person making the release is someone who would have had access to commit to the project's source code anyway.

Is that at least "good enough"? If the root certificate for the package repo's CA were itself signed by a real-world CA, then I think what you end up trusting is the security of the repo, of GitHub, and of the project's developer(s). Projects with multiple committers could have several of them receive certificates, and require a quorum of signatures before a release is published, to mitigate the risk of any one core dev being compromised.

To keep package names trustable, I think the only sane scheme would be using the project's URL on the service which was used to prove its identity; Rails would be "https://github.com/rails/rails", though surely you could use aliases (github:rails/rails) to reduce typing.

[jrochkind1]

As the OP says, if the same organization -- and even likely the same _server_ -- is being the certificate authority and distributing the signed releases....

> However in this model if someone is able to send you a malicious package they are also likely able to send you a malicious key.