Overview

Doc

https://docs.google.com/document/d/1fobWhPRqB4_JftFWh6iTWClUo_SPBnxqbBTdAvbb_SA/edit?usp=sharing

Goals

• Know when a gem on the rubygems server has changed since upload
• Allow for gem to be revoked when it’s malicious
• Patch rubygems binary to warn on insecure downloads

Bonus goals

• Be able to verify the identity of the gem owner
• Be able to verify if gem pulled from rubygems.org was actually built by the gem owner
• Ability to trust multiple CAs (use case - local gem server, alternative gem repositories)

Constraints

• Limit complexity on gem developer side
• Limit complexity on gem user side
• Rubygems is a project run by volunteers so up-front and maintenance costs should be considered

What can we use?

• Currently gems can already be signed using https://github.com/rubygems/rubygems/blob/1.8/lib/rubygems/security.rb
• Breaks constraint #2 - Gem users will need to allow a key for every gem used
• Breaks constraint #1 - Will require a different key setup (not currently easily integrated in system) per gem

See X509 vs OpenPGP for information about the various advantages/disadvantages of X509 and OpenPGP.

Proposal: Chained Trust Model

Rubygems.org (or another delegated organisation) acts as a certificate authority and manages a chain of trust using x509 certificates (or similar) which are used by developers to sign gems.

Read more about the Chain of Trust Model.

How do we handle revocation somewhere in the chain, and how will revocation lists be distributed? - raggi

Multiple options, including OCSP or shipping CRLs with rubygems distributions - jstr

We should look at

• Linux PPA repos
• Apple App Store signing
• Chrome web store signing
• Blackberry signing process

Implementation / Traction

• Forked rubygems.org and rubygems under https://github.com/rubygems-trust
• Request cbetta in #rubygems-trust to get added to the team to work on this