Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security policy questions #15

Open
bbenjamin opened this issue Jan 28, 2021 · 1 comment
Open

Security policy questions #15

bbenjamin opened this issue Jan 28, 2021 · 1 comment

Comments

@bbenjamin
Copy link

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants