mathiasbynens / mathiasbynens/CSS.escape

Security policy questions

Open
#15 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
499
Forks
25
PR merge metrics
No merged PRs in 30d

Description

The Drupal project is considering adding this library as one of our dependencies in order to support the tabbable library in IE11. Before adding any dependency we perform a standard security review. The issue where CSS.escape may be added is https://www.drupal.org/project/drupal/issues/3113649. I acknowledge the likelihood of security issues in your polyfill are low, so I appreciate the time taken to answer these questions.

Since there isn't a policy at https://github.com/mathiasbynens/CSS.escape/security I'm curious if you have any official policies documented somewhere regarding:

Security releases
Were a 2.x release to happen, what would the security release process look like? For example, does more than one version receive security fixes, or only the current version?
Release windows/cadence
This library has been doing its job successfully for a some time without requiring updates, so this may be somewhat hypothetical as well. I assume release happen as necessary on any given day, vs a set schedule after a certain passage of time (e.g. once a month)?
Backwards compatibility guarantees
Were a 2.x release to happen, Are there any guarantees that a given version will be supported for some period of time (an LTS version, for example), also with the understanding that things possibly changed between 4 and 5?
Disclosure Policy
For example, in the event of a security issue would you ask users to report the issues privately, and publish the existence of the vulnerability only once a fix is available, for coordinated disclosure?

If they aren't documented anywhere, could you provide clarification in this issue?

Thanks for your help with our security review process!

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with issue #15 and review its questions about security releases, release cadence, backwards compatibility, and vulnerability disclosure. Done means the project’s official policies are documented or clearly answered in the issue; no files or tests are mentioned.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
documentation, security
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.