A few policy questions

[gabesullice]

Hi there!

The Drupal project is considering adding a library that will add 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 might be a little over the top if this project is a one-person shop, for the most part ;) Due diligence and whatnot.

[wimleers]

Related: is the 2.x branch still actively maintained? (Does it get security releases?)

The library in question is https://github.com/justinrainbow/json-schema, and it uses mac-mabe/php-enum version 2.3.1, which was released on December 21, 2016 (>2 years ago). jsonrainbow/json-schema#464 is working to add 3.x support, but until that materializes, we'd need to know that the 2.x branch of this indirect dependency also gets releases.

[xjm]

Two points we're interested in specifically regarding security coverage:

1. Do you have a process or expectation for reporting and fixing security issues privately for coordinated disclosure?
2. If there is a security issue that affects the package, are you able to coordinate disclosure with other projects as needed?

[marc-mabe]

Hi @gabesullice @wimleers @xjm,

first thanks for your interest in this project and considering using it in a much bigger project :)

Currently this is a small library maintained by me only (with some help of @prolic).
So currently there are no official policies - only semver.

Security releases
For example, does more than one version receive security fixes, or only the current version?

Until now we didn't have any security issues but in case there will be a security issue this will be handled at least like a bug fix (see below) but we can also fix security issues of older versions. We just never thought about this until now and so we didn't provide any official plan.

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

Releases happen as necessary (see in more detail below)

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

Yes it's semver. There are no LTS releases but we do support quite old PHP versions. It's somehow coupled to PHP versions. (see below in more detail)

Two points we're interested in specifically regarding security coverage:
Do you have a process or expectation for reporting and fixing security issues privately for coordinated disclosure?
If there is a security issue that affects the package, are you able to coordinate disclosure with other projects as needed?

As already described - we never thought about this until now.

##################################

What are your expectations on this to be able to use this library?

• Would it be enough to setup a GitHub template noting that security issues should be reported offline with a provided email address.
• Do you have a requirement of min number of people working on a project to be reachable?
• What are your requirements in terms of supported versions?
• Do you need the release process official written down?

#################################

We don't have an official process of how we do handle releases and BC breaks but we do it the following way:

• Semver

  • bug fixes go into patch releases
  • new features go into minor releases
  • BC breaks in major releases (this includes dependency requirements - like required PHP version upgrades)

• Bug fixes will lend into current version (currently 3.1) as well as into last version (currently 2.3) = maintained versions

• depending of the bug we also backport it into older minor releases (3.x / 2.x) - but this happens only for critical bugs

  • PS: I would handle security issues like critical bugs here

• The oldest maintained version has to support at least the oldest maintained PHP version (currently 7.1)

  • But, as you see, we never went into this strict restriction. The current version still supports PHP-5.6 as well as HHVM.
  • The next version (4.x) will require PHP-7.2 and no HHVM but in that time the 3.x version will still be supported

• For BC breaks we try to keep them minimal and also try to provide a migration path into current version

• We document all changes into the released versions - but we don't have a changelog as file

Thanks you very much!
Marc

[xjm]

Thanks so much @marc-mabe for the thorough response! I think a GitHub template providing an email address to report security issues is a great idea.

It's also a good idea to keep a list of contacts for projects that might need coordnated releases. If you ever become aware of an issue that will require a security release, you could contact us at [email protected] to let us know about the upcoming release, and we could use your security email address to pass on any vulnerabilities with the library that are reported to us.

The writeup of your version support policy makes a lot of sense, and the fact that you provide crtiical bugfix support for old branches is great as well. (Drupal has rather long release cycles and non-technical users, so we have to be careful with package major version upgrades.)

Maybe some of the above information could simply be added to your README; I think it gives us enough information to proceed.

[marc-mabe]

Great 😀I'll write it down and let you knowAm 06.03.2019 20:33 schrieb "xjm on Drupal.org" <[email protected]>:Thanks so much @marc-mabe for the thorough response! I think a GitHub template providing an email address to report security issues is a great idea. It's also a good idea to keep a list of contacts for projects that might need coordnated releases. If you ever become aware of an issue that will require a security release, you could contact us at [email protected] to let us know about the upcoming release, and we could use your security email address to pass on any vulnerabilities with the library that are reported to us. The writeup of your version support policy makes a lot of sense, and the fact that you provide crtiical bugfix support for old branches is great as well. (Drupal has rather long release cycles and non-technical users, so we have to be careful with package major version upgrades.) Maybe some of the above information could simply be added to your README; I think it gives us enough information to proceed. —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

[marc-mabe]

@gabesullice @xjm @wimleers

in #117

• I have added a bug report template including a note for reporting security issues at [email protected].
• Added a section for Versioning and Releases in the README

@xjm

... to keep a list of contacts for projects that might need coordnated releases ...

It's impossible for me to maintain such a list as I don't have control of referencing projects, but if you like to open a PR adding a section for Who is using this library I would be open to merge as a way of self managed list by referencing projects.