(Note: Ayo.js is forked from Node.js. Currently, a lot of the documentation still points towards the Node.js repository.)
Ayo.js is a JavaScript runtime built on Chrome's V8 JavaScript engine. It
uses an event-driven, non-blocking I/O model that makes it lightweight and
efficient. Ayo.js, like the rest of the JavaScript
implementations, benefits from the npm package ecosystem, the largest set
of open source libraries in the world.
Contributions, policies, and releases are managed under an open governance model.
This project is bound by a Code of Conduct.
To be written
The Ayo.js project maintains multiple types of releases:
- Current: Released from active development branches of this repository, versioned by SemVer and signed by a member of the Release Team. Code for Current releases is organized in this repository by major version number. For example: v4.x. The major version number of Current releases will increment every 6 months allowing for breaking changes to be introduced. This happens in April and October every year. Current release lines beginning in October each year have a maximum support life of 8 months. Current release lines beginning in April each year will convert to LTS (see below) after 6 months and receive further support for 30 months.
- LTS: Releases that receive Long-term Support, with a focus on stability and security. Every second Current release line (major version) will become an LTS line and receive 18 months of Active LTS support and a further 12 months of Maintenance. LTS release lines are given alphabetically ordered codenames, beginning with v4 Argon. LTS releases are less frequent and will attempt to maintain consistent major and minor version numbers, only incrementing patch version numbers. There are no breaking changes or feature additions, except in some special circumstances.
- Nightly: Versions of code in this repository on the current Current branch, automatically built every 24-hours where changes exist. Use with caution.
More information can be found in the LTS README.
To be written
To be written
See BUILDING.md for instructions on how to build Ayo.js from source. The document also contains a list of officially supported platforms.
To be written
There are no hard and fast rules to determine if a bug is worth reporting as a security issue. The general rule is any issue worth reporting must allow an attacker to compromise the confidentiality, integrity or availability of the Node.js application or its system for which the attacker does not already have the capability.
To illustrate the point, here are some examples of past issues and what the Security Reponse Team thinks of them. When in doubt, however, please do send us a report nonetheless.
-
#14519: Internal domain function can be used to cause segfaults. Causing program termination using either the public Javascript APIs or the private bindings layer APIs requires the ability to execute arbitrary Javascript code, which is already the highest level of privilege possible.
-
#12141: buffer: zero fill Buffer(num) by default. The buffer constructor behaviour was documented, but found to be prone to mis-use. It has since been changed, but despite much debate, was not considered misuse prone enough to justify fixing in older release lines and breaking our API stability contract.
-
CVE-2016-7099: Fix invalid wildcard certificate validation check. This is a high severity defect that would allow a malicious TLS server to serve an invalid wildcard certificate for its hostname and be improperly validated by a Node.js client.
-
#5507: Fix a defect that makes the CacheBleed Attack possible. Many, though not all, OpenSSL vulnerabilities in the TLS/SSL protocols also effect Node.js.
-
CVE-2016-2216: Fix defects in HTTP header parsing for requests and responses that can allow response splitting. While the impact of this vulnerability is application and network dependent, it is remotely exploitable in the HTTP protocol.
When in doubt, please do send us a report.
The Ayo.js project team is comprised of a core team, a moderation team, and various sub-teams. For more information, see GOVERNANCE.md.
| Github | Name | Pronouns | ||
|---|---|---|---|---|
 |
addaleax | Anna Henningsen | anna@addaleax.net | she/her |
 |
aqrln | Alexey Orlenko | eaglexrlnk@gmail.com | he/him |
 |
pup | Olivia Hugger | olivia@fastmail.com | she/her |
 |
Qard | Stephen Belanger | admin@stephenbelanger.com | he/they |
 |
sandfox | James Butler | james.butler@sandfox.co.u | they/he |
 |
TimothyGu | Timothy Gu | timothygu99@gmail.com | he/him |
 |
varjmes | James Spencer | hello@jmes.tech | they/them |
| Github | Name | Pronouns | ||
|---|---|---|---|---|
 |
AgentAntelope | Fell Sunderland | agentantelope+github@gmail.com | he/him |
 |
janl | Jan Lehnardt | jan@apache.org | he/him |
 |
NoahDragon | Abner Chou | hi@abnerchou.me | he/him |
 |
scotttrinh | Scott Trinh | scott@scotttrinh.com | he/him |
 |
siddharthkp | Siddharth Kshetrapal | siddharth.kshetrapal@gmail.com | he/him |
 |
SomeHats | Alex Dytrych | alex@dytry.ch | she/they |
 |
srilq | Stef | stef@srilq.email | they/them |
 |
zkat | Kat Marchán | kzm@sykosomatic.org | they/them |
