---
title: "Sprockets"
description: "3 posts about Sprockets, summarised, each linking to the original."
---

# Sprockets
> 3 posts about Sprockets, summarised, each linking to the original.

## Articles

### [Debugging in Ruby—Busting a Year-old Bug in Sprockets](https://yomu.fyi/post/debugging-in-ruby-busting-a-year-old-bug-in-sprockets.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Richard Schneeman
- Published: Feb 27, 2019
- Type: Tutorial

Sprockets, the Ruby asset packaging system used in Rails’ asset-processing pipeline, had a bug that made assets:precompile fail after a project directory was renamed between runs. The debugging walkthrough reproduces the failure with CodeTriage by clearing caches, compiling assets, moving the project, and compiling again, yielding an error for an outdated absolute path. It then uses bundle open, source inspection, recursive grep, and IRB to examine Sprockets’ dependency cache; the IRB cache lookup does not work because the cache key differs from the cache ID, but the on-disk record exposes an absolute asset path where a relative path is expected. The proposed fix updates loader.rb’s to\_load and to\_link handling with compress\_from\_root, and the pull request adds a regression test.


### [Rails Asset Pipeline Directory Traversal Vulnerability (CVE-2018-3760)](https://yomu.fyi/post/rails-asset-pipeline-directory-traversal-vulnerability-cve-2018-3760.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Richard Schneeman
- Published: Jun 19, 2018
- Type: Incident / postmortem

All previously released versions of Sprockets, which powers the Rails asset pipeline, contained a directory traversal vulnerability, CVE-2018-3760. Rails applications were vulnerable when production runtime asset compilation was enabled with config.assets.compile = true; the default production setting was false, so apps using the default were not vulnerable. Sprockets handled requests by searching for rendered assets and compiling matches dynamically, and an attacker could exploit that process with a crafted URL based on a known absolute source-asset path to make it appear inside a permitted path. Patches were prepared for Sprockets versions 2, 3, and 4, with remediation via disabling runtime compilation or upgrading to versions 2.12.5, 3.7.2, or 4.0.0.beta8. Heroku also updated its Ruby Buildpack to fail affected builds, notified customers, and warned that compromised applications may require credential rotation.


### [Speeding Up Sprockets for Faster Asset Pipelines](https://yomu.fyi/post/speeding-up-sprockets-for-faster-asset-pipelines.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Richard Schneeman
- Published: Feb 22, 2016
- Type: Explainer

The Rails asset pipeline can take over 20 times longer than dependency installation because Sprockets consumes memory, disk I/O, and CPU while reading, fingerprinting, compressing, and resolving dependent assets. Reusing its disk cache failed across Capistrano releases and Heroku builds because cache keys and dependency data embedded absolute paths, so identical files appeared different when compiled from changing directories. Sprockets 3.3+ addresses this with UnloadedAsset, normalized relative cache keys, and URITar, which compresses paths and URIs before caching and expands them when loading; Windows portability was fixed in 3.3.4. In an example app, the initial compile remained about 38 seconds, while the second took 3 seconds, a roughly 1,200% speed increase when compiled assets were reused.