Closed m-o-e closed 9 years ago
feels like much of this is covered in https://github.com/rubygems-trust/rubygems.org/issues/4
According to @evanphx who is one of the principal maintainers of RubyGems, GPG is a non-starter. See #9
@tarcieri This proposal does not use PGP. It uses the existing x509 impl (nearly unchanged).
@m-o-e my bad, was trying to flag the proposals using PGP/GPG, didn't read hard enough ;)
SSH style is appropriate when you know the other party, or know someone who trusts the other party.
The two common cases:
Here, you are in the case where you have to trust a lot of parties that you do not know, so SSH-style might not be the best system. Your idea of relying on someone else to gather lists of keys might be good, though: it allows you to separate the gem handling (which could be decentralized or torrented, for what it's worth) and the key management, which could rely on multiple points of trust to provide "trust agility" (see convergence.io for mor info on the concept).
SSH-Style validation
("SSH-style" refers to prompting the user when he encounters a key for the first time, this scheme has nothing to do with SSH otherwise)
Advantages
Disadvantages
Burdens the users with validation, may need support infrastructure for more convenience (which in turn may be partly centralized)
Implementation
public_key_https_url
The gem author is required to publish his public-key at this URL. The URL may for example point to the project README which contains the public-key (our parser must be smart enough to extract it).public_key_https_url
.The user is asked to inspect the URL and decide whether he wants to download and trust the key at this URL. The actual download and import is then performed automatically after the user confirms. Note: It is up to the user to decide whether he wants to trust a key from https://37signals.ru/README.md to validate the 'rails'-gem he's about to install - this scheme makes no attempt to help him with that.
When a known signing key is encountered the gem just installs without further questions. Obviously the user also always has the option to override and force installation of a gem without validation or import of a key.
What about key revocations?
This is open for discussion, it seems to be a difficult problem in this scheme.
What about convenience?
Being prompted for 400 gems of your rails project is obviously not nice. Hardly anyone is going to verify all of them thoroughly.
I would propose that trusted entities (37signals etc.) frequently publish a list of signing key fingerprints that they trust.
Users could then, in addition to manually trusting individual keys, add such lists to a configuration file, and their local rubygems instance would automatically import trust from there.
The rubygems-program must make it very easy to publish and consume such trust-lists.
Paranoid projects could still refrain from using trust-lists and validate all their gems by hand.
What could it look like in practice?
Early on users would be confronted with many validation prompts. Many users will probably turn validation off for that reason. As adoption grows, and if we add the "trust-list" convenience, people may quickly build a baseline trust-list and then only receive prompts when they install new, relatively unpopular gems.
Final words
It's an imperfect scheme, but so are all others that I have seen so far.
The main argument for this scheme would be the simplicity, as most of the code already exists and no centralized infrastructure is required.
I'm not married to this idea, I just felt it should be written down as a counter-weight to the more complex schemes (the optimal solution is probably somewhere in the middle).