@sbassett Yes, GitHub is the canonical repo.

I fixed the second one of these in https://github.com/wikimedia/stylelint-config-wikimedia/pull/110 (pending merge/release).

The first one needs upstream fixes, unfortunately. dot-prop was removed from postcss-selector-parser all the way back in https://github.com/postcss/postcss-selector-parser/commit/92c0766f8cdb0aa3ffe39a67eaf200c875e23831#diff-b9cfc7f2cdf78a7f4b91a753d10865a2 but stylelint is still using 3.1.1 (latest is 6.x).

Thank you!

@sbassett Are there security policy examples we should orient ourselves on?

In T245070#5881644, @Volker_E wrote:

@sbassett Are there security policy examples we should orient ourselves on?

For node/js dependency vulnerabilities or just in general? The Security-Team does have some developer best practices/documentation up on mediawiki.org, though some of that is a bit dated and very PHP/MediaWiki-centric. The most relevant item might be our Third Party Code Review Checklist, which we use as a basic set of guidelines for various internal reviews. At some point, I would very much like to clean up our older documentation and craft some new documentation targeted towards other languages such as node/js, golang and python.

For the node/js dependency vulnerabilities specifically, we tend to find many of those during our security readiness reviews but would certainly encourage all technical contributors to do any of the following:

1. run various tools like npm audit, snyk test, nvd searches, etc. manually during development cycles
2. build npm cli commands which can run the aforementioned security checks in an automated fashion
3. configure CI for relevant repositories to have various security checks run during code review (non-voting is fine)
4. configure github to automatically check for relevant security alerts
5. feel empowered to create Phab tasks like this one to request updates for vulnerable and outdated dependencies

If this isn't really what you were asking or you have any further questions, please feel free to contact us directly.

@sbasset Was referring to your last point about setting up a formal security reporting policy in the repo. AFAICT stylelint features a pretty simple[[ https://github.com/stylelint/stylelint/blob/master/SECURITY.md | SECURITY.md file ]].

@Volker_E Ah, ok, sorry about that. I would say any policy/SECURITY.md could borrow heavily from the existing Reporting Security Bugs doc (or even just link to it). Otherwise, providing an email (even better with a public key) and reminding folks that they shouldn't just open a public issue or create a pull request should suffice.

Update: upstream has tagged a new release that updates postcss-selector-parser and thus mitigates the prototype pollution vulnerability. So whenever we can upgrade stylelint-config-wikimedia to use stylelint@13.2.0, that would fix the issue on our end.

PR for stylelint-config: https://github.com/wikimedia/stylelint-config-wikimedia/pull/111

PR for grunt-stylelint: https://github.com/wikimedia/grunt-stylelint/pull/84

Note there's also https://github.com/wikimedia/grunt-stylelint/network/alert/package-lock.json/diff/open which is looking to be harder to fix.

Released as https://github.com/wikimedia/grunt-stylelint/releases/tag/v0.14.0 and https://github.com/wikimedia/stylelint-config-wikimedia/releases/tag/v0.9.0 ; I've configured LibraryUpgrader to do org-wide upgrades where possible, which all should land over the weekend, hopefully.