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