Upgrade crass to 1.0.7#442
Conversation
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
🤖 Upgrade Plan: crass 1.0.6..1.0.7Upgrade Plan: crass 1.0.6..1.0.7 for writebook
Summary
Bottom line: Upgrade crass 1.0.6 → 1.0.7. It is a single transitive bump through loofah How writebook reaches crasswritebook does not call crass directly. It reaches it through the Rails HTML-sanitization chain: Any path that sanitizes untrusted HTML containing inline Commits Requiring MitigationAll four are backwards-compatible DoS fixes inside crass's tokenizer/parser. None changes output ea6726b7 — Prevent resource-exhaustion DoS via excessively large exponentsunlikely impact · GHSA-6wmf-3r64-vcwv. 25d78cc6 — Prevent a long run of adjacent comments from exhausting the stackunlikely impact · GHSA-wwpr-jff3-395c. ~12,000+ adjacent CSS comments could recurse the da296646 — Fix inefficient handling of non-ASCII characters during tokenizationunlikely impact · GHSA-8vfg-2r28-hvhj. Many non-ASCII characters caused O(n) multi-byte cf682873 — Limit recursion depth to prevent stack overflow / memory exhaustionlikely impact (low behavioral risk) · GHSA-6jxj-px6v-747w. Adds default Mitigation (all four): Execution
No Impact (Skipped)22 of 26 commits assessed as "no impact" during recon — CI matrix churn, dev-dependency bumps, Shared recon for this range applies to every loofah-using app. Deepest app-level exposure |
Summary
Upgrade crass 1.0.6 → 1.0.7 (transitive, via loofah). Closes four DoS-hardening fixes in crass's CSS tokenizer/parser (GHSA-6wmf-3r64-vcwv, GHSA-wwpr-jff3-395c, GHSA-8vfg-2r28-hvhj, GHSA-6jxj-px6v-747w).
No application code changes — pure lockfile bump. bc3 and fizzy already run 1.0.7 in production. Full analysis posted as a comment below.
🤖 Generated with Claude Code