Skip to content

Overview

raggi edited this page Feb 10, 2013 · 11 revisions

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?

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

Something went wrong with that request. Please try again.