A few policy questions

[gabesullice]

Hi there! And thanks for all your excellent work, this library has been super helpful :)

The Drupal project is considering adding this library as one of our dev dependencies and so we're performing a standard stability review.

I'm curious if you have any official policies documented somewhere WRT to:

• Security releases
  • For example, does more than one version receive security fixes, or only the current version?
• 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)?
• Backwards compatibility guarantees
  • I see the project uses semver, so I assume the major version promises not to break BC. However, is there any guarantee that a version will be supported for some period of time (an LTS version, for example)?

PS. I totally understand that these questions are probably a little over the top if this project is a one-person shop, for the most part ;) Due diligence and whatnot.

[bighappyface]

Hey, @gabesullice.

Thanks for reaching out.

There are no official (i.e., written) policies for this package.

For security releases, we would do the best effort to patch affected versions. Most fixes and updates are backported, but we don't have branches for versions older than v5.

There is no regular release cadence. Releases are mostly PR-driven and covered in PR discussions.

Yes, the use of semver is in place to provide BC assurances. There is no guarantee, per se, but I think the conventional SDLC provides general coverage.

I don't think the questions are over-the-top, and we are honored to be considered for another large project. Simply put, this is a 100% community-driven package, and certainly the labor of love for @erayd and @shmax.

[gabesullice]

Thanks for that info @bighappyface ! It's much appreciated :)

[wimleers]

BTW, related: #464.

[xjm]

Thanks so much for the quick response!

One followup question on security practices -- do you think you will mostly practice coordinated disclosure for any security issues that might come up? For example, do you have any mechanism for handling security bugs privately before they are fixed?

And, more specifically -- if you do become aware of a security issue that will require a security release for the package, can you reach out to us and let us know? Our security team's contact address is security@drupal.org.

[bighappyface]

@xjm no means of private disclosure of security issues is available at this time, but it is fair to get something established. Perhaps some documentation about security procedures with a list of important contacts to notify would be an acceptable first step?

[xjm]

@bighappyface That sounds like a great idea to me.

[erayd]

@wimleers @xjm

I would like to point out that manpower is something you guys should be aware of if you're intending to depend on this library. We're extremely short on manpower - it's basically just me and @shmax for the most part, and unless I'm working for a client who is paying me to make major progress on this (which is uncommon, but happens sometimes), I just don't have the time available to do significant amounts of work. As a result, progress on 6.0.0 has been extremely slow, and we currently don't have full support for any version of the spec newer than draft-04.

I have been backporting stuff into the 5.x.x branch in order to ensure ongoing support, bugfixes, and backwards-compatibility on that branch, and intend to continue this. Basically every applicable bugfix goes in there, plus features that make sense to backport without breaking backwards-compatibility. We comply strictly with semantic versioning, and will continue to do so. If you have a specific requirement for what you actually need regarding LTS support, that would be good to know, so we can give a better indication on whether your requirements are actually something we can comply with in that regard. I suspect it'll be fine, but it seems important to check. We're also a dependency of composer, so we are unlikely to drop support for 5.x.x any time soon.

Security-wise, we've not had any issues reported during the years I've been involved with the project, but we also haven't had (as far as I'm aware) any significant auditing of the code either, and there's a lot of old, messy stuff in there, so it would not surprise me if there were a few such problems with it. I'm happy to commit to addressing any security concerns that are raised extremely quickly, but I can't promise that they will be proactively discovered, due to the aforementioned lack of time. A responsible disclosure policy and contact list is not something we have at present, but IMO it's a good idea, and I'd be quite happy for us to go down that path.

One other risk to be aware of is that this repo has a very high bus factor - @justinrainbow has been AWOL for years, and the only person who has commit access is @bighappyface. We can't add anybody else, because @bighappyface doesn't have admin rights to the repo. We could move to a new package name if necessary, but that would be rather messy.

[xjm]

Thanks @erayd !

Regarding the bus factor, hopefully our contributors can help out upstream too. :) I know this package has been very helpful to contributors to the Drupal JSON:API module, so I'm sure it's in their interest to help out if or when they can.

Drupal's release schedule is as follows:

• Current major version (Drupal 8) will be EOL in November 2021.
• Next major version (Drupal 9) will be released in either June or December 2020.
• Drupal 9's EOL is TBD but will probably be November 2024 at the earliest.
• Minor versions are released every six months (next is May 1, but thereafter they will be consistently in December and June). Each minor receives six months of active bugfix support followed by six months of security-only support.
• An LTS minor of Drupal 8 will be released the same day as Drupal 9.0.0 (identical to 9.0 except 9.0 has deprecations removed and dependencies updated), and will receive only bugfixes until Drupal 8's EOL.
• Patch releases happen on the first Wednesday of each month.
• We practice coordinated disclosure. Because of our large non-technical install base, Drupal tends to get a lot of private security reports about vulnerabilities in our upstream dependencies, and we will always pass on these reports privately (and sometimes help fix them if we can).
• To facilitate coordinated disclosure with our third-party ecosystem and Drupal sites, Drupal core security release windows are on the third Wednesday of the month (except in the case of a zero-day which may lead to a release on a different Wednesday, or immediately, depending on the severity). When an upstream package has a security release that is exposed in Drupal, we try to coordinate disclosure on the third Wednesday if it's possible for the other package maintainers. (Edit: We're also trying to bring this to the whole PHP community as a standard; I forget which PSR but it's maybe related to PSR-9 or PSR-10.)

Sorry to hear about the admin rights issue; that's a tough spot to be in.

[bighappyface]

@xjm bus factor has increased from 1 to 3. Both @erayd and @shmax now have write permissions on this package.

[shmax]

Huzzah! Thanks @bighappyface , and @justinrainbow , wherever you are...

[DannyvdSluijs]

@gabesullice and @xjm in an attempt to cleanup this repo we are trying to filter the issues and see which ones might be closed. Is it safe to assume all questions were answered and this issue can be closed? Feel free to close it yourself with some comments if helpful or let us know what is needed to progress on this.

[gabesullice]

Thanks for your input everyone. I'm glad the commit access issues were sorted out. Y'all went above and beyond. I think all questions were sufficiently addressed for our purposes. Huzzah!