Open nyarly opened 11 years ago
I believe @emboss had some concerns about this type of approach...
Which concerns exactly?
Was hoping @emboss would opine... I can't really remember what they were offhand.
One problem I could see is that project ownership could be overridden quite easily.
@geal I'm not sure how that would be? Rubygems would still be responsible for controlling who can push. Also, the assertion of "this gem is benign" is made separately from "anyone of consequence trusts me to make that assertion" - either my key needs a WoT chain to a deployment (in a WoT scenario) or the CA needs to back up my rights to verify that gem.
@nyarly the problem lies with the central authority. With a CA or a WoT, gem ownership depends on the good will of the rubygems maintainer.
Well, in a separated verification system, it would for me to take the code inside your gem, start a new repo, make changes and distribute it via a source I control. (Well, that's possible now.) But unless you'd consented, I couldn't get you to mark the gem legit/benign, and so (presumably) there'd be a much smaller audience for my version.
On the other hand, ownership could be no harder to transfer than it was before, since if there's any sort of CA or notaries system, you can let them know (via a signed standard message: {gem,<nyarly's cert>,add_owner}) that I should be recognized and a signatory on the gem.
(That expands the purposes of the key system, and implies a new kind of verification: "I trust Gael's signature to sign gems of this name" as opposed to "I trust Gael's signature for all gems.")
This is an idea that's appear in common to a few proposals, that I wanted to separate out and discuss the merits of.
As currently provided, gem verification signatures exist within the gem itself, and are purely an assertion that "I am the author of this gem."
What I'd like to propose is that anyone with a private key be able to sign and publish a verification of any gem. The sense of the implied assertion becomes "I've reviewed this gem and consider it safe to use."
The value of that assertion depends on how a particular deployment environment trusts the public key of the signer.
Benefits and motivations
Gems authored by a deployer can be iterated quickly, since the deployer can trust their developer's key directly without asking for validation from an outside party.
This would enable a "notary" role who volunteers to sign some subset of gems.
The trust model shifts from caring about who wrote a gem to caring who says a gem is safe to use.