mathiasbynens / CSS.escape

A robust polyfill for the CSS.escape utility method as defined in CSSOM.
https://mths.be/cssescape
MIT License
491 stars 31 forks source link

Security policy questions #15

Open bbenjamin opened 3 years ago

bbenjamin commented 3 years ago

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!

mathiasbynens commented 3 years ago

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?

In that scenario I'd backport the fix to v1.x (or would accept a patch doing so) and release a semver patch update, so that both v2 and v1 are patched.

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)?

No strict schedule. I release when it's necessary.

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?

There's no guarantees. I maintain this as a hobby project, for free, in my spare time.

(Most of these questions are hypothetical indeed. There's unlikely to be many major new versions -- this is a polyfill that at present correctly polyfills the web API it's supposed to polyfill.)

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?

I would appreciate responsible disclosure indeed.