tschneidereit commented 3 months ago

Proposing the adoption of StarlingMonkey as a Bytecode Alliance hosted project.

Repository URL: https://github.com/bytecodealliance/StarlingMonkey

StarlingMonkey

StarlingMonkey is a component-native JavaScript runtime targeting WASIp2 or other sufficiently capable host environments. It's designed to be highly modular and is easily extensible with additional builtins.

StarlingMonkey is built on SpiderMonkey, the JS engine used by Firefox, and is thus highly spec compliant and extremely robust. Additionally, it includes an implementation of various web standards, such as the fetch API, WHATWG Streams, and a subset of the Web Crypto API.

StarlingMonkey is derived from Fastly's js-compute-runtime project, but has been significantly refactored and extended to be more modular and embeddable as part of an effort to integrate it into Fermyon's JS SDK for the Spin runtime.

(Note to observers: the StarlingMonkey repository is already in the Bytecode Alliance organization, but it's not yet an official Bytecode Alliance project. This was agreed on by the TSC a few months back, with this proposal being intended to formalize the status as a hosted project.)

Requirements

Alignment with the Bytecode Alliance Mission

I believe StarlingMonkey project aligns strongly with the Bytecode Alliance Mission by providing a robust toolchain for using JavaScript to develop WebAssembly Components.

StarlingMonkey is designed to be embeddable and extensible through hooks in its CMake based build system: it can be integrated into downstream projects and extended with additional builtins without changes to the code base itself. Additionally, all builtins are configurable and StarlingMonkey's host API is abstracted such that it can target other environments than WASIp2, meaning that the runtime can be tailored to the specific needs of downstream integrations.

One such integration is the existing ComponentizeJS project, through which it is easy to target arbitrary WIT interfaces using JavaScript without the need to compile custom runtimes.

Code Review

Description

Reviews by the members of the starlingmonkey-core team are required for all PRs, with a high code quality standard for all changes.

Code of Conduct

The project follows the Bytecode Alliance Code of Conduct.

Continuous Integration Testing

StarlingMonkey has a continuous testing setup consisting of multiple kinds of tests:

End-to-end tests that fully provide their own code and are checked against expected output
Integration tests using a JS harness and testing builtins such as assertions
A harness for running a relevant subset of the Web Platform Tests suite, ensuring a high degree of spec conformance of the implementations of builtins.

Contributor Documentation

The repo contains a README file that provides an overview of the project and how to build and run it. An issue is on file to provide more technical and architectural documentation and expand on conbtributor facing docs.

Following the Bytecode Alliance Operational Principles

The StarlingMonkey project is committed to be interoperable with other projects and follows a standards-first approach: it targets WASIp2 and aims for high compliance with web standards wherever applicable.

Licensing Compatible with the Bytecode Alliance

Currently, the project uses the BA's default license, Apache-2.0 WITH LLVM-exception, for all code in the repository. There's an intent to import Rust code under the MPL-2.0 license, which is compatible with the Apache-2.0 license and used by the upstream SpiderMonkey project. The Bytecode Alliance's board of directors has already granted an exception for this as required by the BA's IP policy.

README

A README can be found at https://github.com/bytecodealliance/StarlingMonkey/blob/main/README.md

Upon acceptance of this application, a header indentifying StarlingMonkey as a Bytecode Alliance project will be added.

Release Process

StarlingMonkey itself doesn't have an automated release process yet, but one is available through the integration into the ComponentizeJS project. An issue is on file to automate the release process for StarlingMonkey itself.

Security Process

StarlingMonkey is fully run in a sandboxed environment and doesn't have access to the host system, so the attack surface is significantly reduced. Nevertheless, an issue is on file for defining a formal security process for the project.

Semantic Versioning

The project itself doesn't yet have any formal releases. Instead, ComponentizeJS and other downstream projects update the version used by depending on a specific commit hash. An issue is on file to implement semantic versioning for the project.

Secrets Management

The project doesn't handle any secrets at the moment. If and when that changes, it will use GitHub secrets for repository-wide secrets.

Supply Chain Security

StarlingMonkey has few upstream dependencies, with the most notable ones being SpiderMonkey and OpenSSL—both projects with a very high level of scrutiny.

In both cases, official release versions are used, with additional patches carried downstream where needed.

Sustainable Contributor Base

StarlingMonkey receives regular contributions from multiple developers working at multiple organizations, and has a core maintainer team with members of two different Bytecode Alliance member organizations.

Version Control

StarlingMonkey is already hosted in the Bytecode Alliance GitHub organization.

Recommendations

Changelog

The project will follow keepachangelog.com once it's feature-complete and 1.0 version is released.

Continuous Fuzzing

no fuzzing is currently performed. While it'll make sense to eventually change that, the fact that the runtime is fully sandboxed and doesn't have access to the host system significantly reduces the attack surface.

End-User Documentation

StarlingMonkey itself doesn't really contain end-user documentation, as it's intended to be embedded into other projects. However, the ComponentizeJS project provides a high-level overview of how to use the runtime.

Issue Triage Process

The project uses GitHub to track issues and manage pull requests. A GitHub project is used to track blockers for a 1.0 release.

Leverage the Bytecode Alliance RFC Process

StarlingMonkey does not leverage the RFC process yet, mostly due to being a new project, which is not feature-complete yet, but it's intended to do so as part of the stabilization process.

Production Use

Multiple organizations are already using StarlingMonkey in production, including Fastly and Fermyon as part of the JS SDKs for their platforms.

Public Project Meetings and Notes

Currently, no public meetings are taking place for StarlingMonkey, but the JS subgroup of SIG-guest-languages is used to discuss the project.

Sanitizers and Code Analysis

SpiderMonkey is fully running inside the WebAssembly sandbox, making the use of sanitizers less critical. However, the project is considering adding sanitizers to the build process to catch potential issues early.