Security Policy
Supported versions
Section titled “Supported versions”| Version | Where | Status |
|---|---|---|
| Latest 2.x release | master (until v3 is promoted to it at v3.0.0), v2.x, the latest v2.* tag |
Supported until twelve months after v3.0.0 |
v3 pre-releases (v3.0.0-alpha.N, -beta.N, -rc.N) |
next |
Best effort |
| Older 2.x releases, 1.x | older v2.* tags, v1.* tags |
Not supported: upgrade to the latest 2.x release |
Security fixes for 2.x are released as a new 2.x patch release. 2.x stays
supported for twelve months after v3.0.0 is released, as decided in the v3 plan
(docs/proposals/v3-plan.md
on next, section 7, item 11). When v3.0.0 is released, the end date is added
here and in the README, and this table gets a row for 3.x. Which branch holds
which line is described in Branch strategy.
ngx_mruby trusts the nginx configuration and the Ruby code that it loads, and
treats what a client sends as untrusted input. A defect of ngx_mruby that makes
it read or write memory outside its buffers, end or hang the worker, or reveal
or change the data of another request, in a configuration that uses the
directives and methods as they are documented, is in scope, in particular when
input a client controls triggers it. What follows from the operator’s own code
doing what it was written to do (for example a script that passes client input
to eval, a shell command or a file path), and a setup that takes configuration
or Ruby code from parties that the operator does not trust, are not. Trust
boundary describes both sides and the scope in
full. If you are not sure whether a defect is in scope, report it privately.
Reporting a vulnerability
Section titled “Reporting a vulnerability”Please do not report security vulnerabilities through public GitHub issues, pull requests or discussions.
Report them privately with GitHub’s private vulnerability reporting: open the repository’s Security tab and click Report a vulnerability (https://github.com/matsumotory/ngx_mruby/security/advisories/new).
If that form is not available to you, open a public issue that only asks for a private contact channel. Do not include any details of the problem in it.
What to include
Section titled “What to include”- The ngx_mruby version or commit, the nginx version and its configure options,
the OpenSSL version, and any changes to
build_config.rb - A minimal
nginx.confand the Ruby code involved - Steps to reproduce, and the expected and actual behavior
- The impact as you understand it (for example crash, memory disclosure, denial of service) and the conditions an attacker needs
- Any backtrace, sanitizer or valgrind output
- Whether the issue is already known to others, and how you would like to be credited
What to expect
Section titled “What to expect”ngx_mruby is maintained by volunteers, so there is no guaranteed response time. We will acknowledge your report, keep you informed in the advisory, and may ask for more details. If you have not heard back after two weeks, please post a reminder in the same advisory.
Coordinated disclosure
Section titled “Coordinated disclosure”- The fix is prepared privately (in the advisory’s temporary private fork) and released as a new version.
- The advisory is published when the fixed release is available, with a CVE where appropriate. Reporters are credited unless they prefer otherwise.
- Please keep the issue confidential until the advisory is published, or until we agree on a disclosure date with you.
Vulnerabilities in bundled or third-party components (mruby, nginx,
ngx_