Proposal 3: "SSH style"

[m-o-e]

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

• Very simple to implement and understand (most of it already is implemented)
• Does not require any critical, centralized infrastructure
• Helps with the most pressing issue of gem integrity validation (verify that a gem originates from a particular author/URL)

  Disadvantages

• Burdens the users with validation, may need support infrastructure for more convenience (which in turn may be partly centralized)

  Implementation

  1. Just use the x509 signing as it's already implemented today.
  2. Introduce new gemspec-field 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).
  3. Enforce signing Change rubygems.org to reject pushes of gems that contain no signature. This forces gem authors to generate a keypair and start signing their gems.
  4. Validation During installation, when an unknown signing key is encountered (not present in the local keyring), the user is prompted with the gem-name and the 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

1. 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).

2. The convenience mechanisms outlined above would re-invent a few wheels that already exist (PGP). Just using PGP directly might thus be preferable, but requires a higher implementation effort.

[danielknell]

feels like much of this is covered in https://github.com/rubygems-trust/rubygems.org/issues/4

[tarcieri]

According to @evanphx who is one of the principal maintainers of RubyGems, GPG is a non-starter. See #9

[m-o-e]

@tarcieri This proposal does not use PGP. It uses the existing x509 impl (nearly unchanged).

[tarcieri]

@m-o-e my bad, was trying to flag the proposals using PGP/GPG, didn't read hard enough ;)

[Geal]

SSH style is appropriate when you know the other party, or know someone who trusts the other party.

The two common cases:

• SSH, where you manage the server, so you know when the fingerprint changes (or someone you trust gives you the fingerprint)
• OTR, where you have a side channel to verify the connection

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).