search

marc-mabe / php-enum

Simple and fast implementation of enumerations with native PHP
BSD 3-Clause "New" or "Revised" License
464 stars 36 forks source link

A few policy questions #112

Closed gabesullice closed 4 years ago

gabesullice commented 5 years ago

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:

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 commented 5 years ago

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). https://github.com/justinrainbow/json-schema/pull/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 commented 5 years ago

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 commented 5 years ago

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?

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

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

Thanks you very much! Marc

xjm commented 5 years ago

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 security@drupal.org 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 commented 5 years ago

Great 😀I'll write it down and let you knowAm 06.03.2019 20:33 schrieb "xjm on Drupal.org" notifications@github.com: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 security@drupal.org 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 commented 5 years ago

@gabesullice @xjm @wimleers

in #117

@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.