Update decade-old Gemfile.lock and jQuery to clear security alerts - #138
Draft
jlepp wants to merge 1 commit into
Draft
Update decade-old Gemfile.lock and jQuery to clear security alerts#138jlepp wants to merge 1 commit into
jlepp wants to merge 1 commit into
Conversation
Gemfile.lock was frozen at github-pages v116 (~2016) and had accrued all 63 open Dependabot alerts (5 critical: nokogiri x4, kramdown x1). Regenerated with Ruby 3.3 to github-pages 232 - the same version GitHub's Pages build servers use - which resolves every flagged gem at or above its patched version: nokogiri 1.6.8.1 -> 1.19.4 kramdown 1.11.1 -> 2.4.0 jekyll 3.3.0 -> 3.10.0 activesupport 4.2.7 -> 8.1.3.1 faraday, addressable, concurrent-ruby, json all current Note: production is unaffected either way - the site deploys via the legacy Pages build, which uses GitHub's own gem set and ignores this lockfile. This only fixes local dev (the old lockfile no longer even installed on modern Ruby) and clears the alert backlog. Also bump the CDN jQuery 1.9.1 -> 3.7.1, which predated the CVE-2020-11022/11023 htmlPrefilter XSS fixes and was the only alert-era code actually served to visitors. Site JS uses no jQuery-3-removed APIs; verified locally (jekyll build + Chrome): 83 repos render, isotope language filters work, and the rate-limit-degraded path still renders.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Two dependency updates that clear the repo's entire security-alert backlog (63 Dependabot alerts, 5 critical) plus the one vulnerable-era library actually served to visitors.
1. Regenerate
Gemfile.lock(github-pages 116 → 232)The lockfile was frozen at github-pages v116 (~2016) — nokogiri 1.6.8.1, kramdown 1.11.1, activesupport 4.2.7 — and had accumulated all 63 open Dependabot alerts. Regenerated with Ruby 3.3 (matching GitHub's Pages build environment), resolving every flagged gem at/above its patched version:
Risk context: production is unaffected either way — this site deploys via the legacy Pages build, which uses GitHub's own gem set server-side and ignores the committed lockfile. This change fixes local dev (the old lockfile no longer installs on any modern Ruby) and clears the alert backlog.
2. jQuery 1.9.1 → 3.7.1 (CDN)
jQuery 1.9.1 predates the CVE-2020-11022/11023
htmlPrefilterXSS fixes (patched in 3.5.0) and was the only vulnerable-era code actually shipped to browsers. Audited the site's scripts for jQuery-3-removed APIs (.size(),$.browser,.live(), etc.) — none used; the vendored isotope v2 uses the bridget adapter, which is jQuery-3-compatible.Testing
bundle install && bundle exec jekyll buildsucceeds on the new lockfile (Ruby 3.3)is-loadedset