Gem Integrity - Subresource Integrity (SRI) for Ruby

[br3nt]

I want to start the discussion of introducing the concept of Subresource Integrity (SRI) into the Gemfile.

Here is an example of what it may look like:

gem 'some_gem', '~> 2.4.4', integrity: ['sha256-sdf...', 'sha384-cxg...']

The goal is exactly the same as SRI but translated to gems:

Gem Integrity is a security feature that enables bundler to verify that gems fetched from a source (for example, RubyGems, a private source, or a proxy) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched gem must match.

If an attacker gains control of a gem repository, the attacker can inject arbitrary malicious gems and thus can also potentially attack all applications that fetch gems from that repository.

Gem Integrity enables you to mitigate some risks of attacks such as this, by ensuring that the gems have been delivered without without any changes of any kind having been made to it's contents.

Using this technique, it would be more or less impossible for a gem version to be replaced with a malicious one as it will not match the specified hash and therefore will never be installed.

To enable this feature, there will need to be a standardized technique to determining the hash of a gem. Likewise, the hash would need to be made public by gem authors and possibly the gem repositories. E.g RubyGems.

Having Gem Integrity, will help to protect the Ruby community from malicious actors.

Using Gem Integrity as a foundation, we could also provide additional value added features. Some ideas are:

• Gems deemed as containing security vulnerabilities could be added to a blacklist
• Specific gem versions could be marked as trusted by community members building a web of trust
• Tools can be used to evaluate if any gems (or their dependencies) have been blacklisted, or have a low trust value. Developers could then set a minimum trust threshold for gems in their project.

I would love to hear everyone's thoughts on this.

[br3nt]

One problem with this approach is that there is no integrity checking for implicit gem dependencies as the actual versions of the dependencies are negotiated rather than explicitly defined.

I'm not sure how to get around this limitation... yet

[graingert]

@br3nt

https://rubygems.org/ could maintain a transparency log of all assets published. When building your Gemfile.lock you could include the latest transparency log merkle root in that file:

  remote:
    url: https://rubygems.org/
    tlroot: 071f9a0b73fa9523fed851d55743a9fa09e29f705f10e890a3a56e37749fc011
  specs:
...

The latest tl root would be presented somewhere prominently on the website and "bundle lock" would update it.

then for every package downloaded rubygems would need to present the path in the transparency log to the hash of the asset requested.