Security policy questions

[bbenjamin]

The Drupal project is considering adding this library as one of our dependencies and so we're performing a standard stability review. We're looking into adopting this in https://www.drupal.org/project/drupal/issues/3113649. I fully acknowledge the likelihood of security issues tabbable are very low, so I particularly appreciate the time taken to answer these.

Since there isn't a policy at https://github.com/focus-trap/tabbable/security I'm curious if you have any official policies documented somewhere regarding:

Security releases
For example, does more than one version receive security fixes, or only the current version? It looks like 5.x is the first after the maintainer switch, so this may not apply currently, but would like to know if it would be applicable with a >=6.x release.
Release windows/cadence
For example, do they happen as necessary on any given day, or on a set schedule after a certain passage of time (e.g. once a month)? Looking at all the recent releases (which is great to see!), I can probably make some assumptions, but would like to confirm.
Backwards compatibility guarantees
Tabbable uses semver, so I assume the major version promises not to break BC. Are there any guarantees that a geven 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?

Thanks, I'm pleased to see all the recent activity on this library!

[stefcameron]

👋 Thanks for reaching out about this! It's cool to see a project as big as Drupal considering using tabbable!

In response to your questions:

• Security releases: I'm also maintaining focus-trap and focus-trap-react (all in the same org/family), so the only thing I can support is the currently released version. If there's a security issue in that version, then I'll certainly fix it by publishing a new version that addresses the vulnerability, but I will not support any previous versions. So if I eventually publish 6.0.0 and a security issue is found in 5.1.3, for example, and it's still in 6.0.0, then I will fix it in 6.0.1 or 6.1.0 (or possibly 7.0.0 if it requires breaking backward compatibility for some reason -- I would imagine this would be rare), but I will not also publish 5.1.4 or 5.2.1 to fix it.
  I guess there could be a scenario where I'm in a pre-release on a new major and a security issue is discovered in the current 5.1.3 release. In that case, I'd try to fix it in the current non-pre-release, and bring that forward into the pre-release, but that's as far back as I would go (though I don't consider that going back because the latest release isn't a "full" release, it's still in pre-release stage, so I don't expect everyone to want to adopt a pre-release to get security fix).
• Release cadence: This happens whenever there's something new to publish, regardless of the Semver bump. So far, that's only patches and minors. I did do a major when I took over, but I did that out of an abundance of caution because the project had stagnated for an entire year and I bumped all the dependencies and refactored the build, etc., when I took over. So I wanted to send a clear message there, that upgrading might cause issues.
  But now, I haven't come across anything in this library that would warrant a major bump. If I did, I guess that would be a complete change to the API, or something like no longer recognizing a node as tabbable which was previously recognized as tabbable (for example). I don't think I would have a big release plan for that, though, given the size of the library. I would probably leverage a pre-release version, like 6.0.0-alpha.1, to test the waters in the community until it stabilizes, and then publish 6.0.0.
• Backwards compatibility: This is only guaranteed within a major, not from one major to the next. Semver states that, "the major version is incremented if any backwards incompatible changes are introduced." That's what I would respect. Patches are bug fixes that remain backward compatible (to the current major), minors for new features (or significant internal changes) that remain backward-compatible (to the current major), and majors are for breaking changes (from the previous major).

Thanks for asking these questions! I created #142 to remind myself to add a security policy to this repo. 😄 Please let me know if I can help further or if you need any clarifications. If not, then please close the issue so I know you have the info you need.

[xjm]

Thanks @stefcameron !

One other question about a hypothetical security issue: What would your policy on disclosure be? For example, would you ask users to report security issues privately, and publish the existence of the vulnerability only once a fix is available, for coordinated disclosure?

[stefcameron]

Thanks @stefcameron !

My pleasure.

One other question about a hypothetical security issue: What would your policy on disclosure be? For example, would you ask users to report security issues privately, and publish the existence of the vulnerability only once a fix is available, for coordinated disclosure?

Yes, I would ask for private report and coordinated disclosure once a fix is available, though I'm not sure where I would publicly disclose it. I guess the most appropriate thing to do would be to put a notice on the README about the vulnerability found in version X and a strong recommendation to upgrade to version Y ASAP. But know that there would be zero incentive for the person who finds the vulnerability to keep quiet until a fix is available, other than their good conscience. I'm not going to offer rewards or anything of the sort.

[xjm]

Great to hear; thanks! In my experience most researchers are happy to follow each project's disclosure policy if it's clearly defined. It helps to simply credit the researcher(s) who report an issue when disclosing it ("Hall of Fame" program).

GitHub actually added a feature for security advisories last year, which automatically notifies other GitHub projects that declare a dependency: https://github.com/focus-trap/tabbable/security/advisories Works quite nicely. One can write the security policy on the same tab as well: https://github.com/focus-trap/tabbable/security/policy

[stefcameron]

@xjm Thanks for the info on the security advisories. I'll check that out for #142. I guess we could add a "Hall of Fame" section to the README similar to our "Contributors" section, but dedicated to highlighting those who have found and reported security issues per our disclosure guidelines.

I'll assume I've answered all your questions at this point and will close this issue. If that's not the case, please re-open it or LMK and I can re-open it.