-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Core Project Proposal: The Wasmtime Project #114
Comments
In review of the GitHub teams access, I noticed that there is potentially an additional team that appears to have been renamed and |
Who has access to wasmtime-publish user? How is this managed? Does the TSC have access? |
There is a secret, PERSONAL_ACCESS_TOKEN that is 3 years old and does not appear to be used. Can it be removed? CARGO_REGISTRY_TOKEN was updated last month. Where is this used? |
I don't have much to add on the github teams aspect other than "I definitely agree it could probably be cleaned up!" as it's mostly been a home-grown mishmash over the years. I can answer some others more specifically though:
I believe only I have access. The goal is to move the credentials to the TSC 1password and ideally retain the ability for at least one non-TSC member to still have access to these credentials (e.g. me). I don't have a concrete plan of how to migrate credentials but if the board/tsc decision is that I as a project member can have access to the BA 1password then when I get added I can move the credentials from my personal 1password into the BA which can then get moved around. In terms of management right now it's a github account with the email pointing at my own personal email and the password/2fa are stored in my own personal 1password. The TSC does not currently have access (or at least not that I know of)
This is a personal access token for the This is only used to create PRs from CI AFAIK.
This is used when we publish the wasmtime/cranelift/pulley/etc crates from CI. AKA part of the release process. Last month I created a new crates.io token for the wasmtime-publish user and configured it here. The crates.io token is customized to only allow publishing updates/new crates and doesn't allow yanks for example. Additionally it only allows crates in a few namespaces we work within (e.g. |
There are two relatively minor things I've caught on my read-through.
We'll need an explicit link to the BA code of conduct from the Wasmtime code of conduct. They're currently the same version of the Contributor Covenant code of conduct, but this might not always be the case.
It looks like there's a mention of doing issue triage in the Wasmtime meeting template, but we should add a callout in the CONTRIBUTING.md that says triage happens at every meeting. I'm happy to send PRs for these if there are no objections! |
Yes please do, that would be most welcome! |
Proposing the promotion of Wasmtime to a core project.
Repository URL: https://github.com/bytecodealliance/wasmtime/
Wasmtime is a lightweight WebAssembly runtime that is fast, secure, and standards-compliant
Requirements
Alignment with the Bytecode Alliance Mission
From its inception as a project, Wasmtime has been focused on the same goals the Bytecode Alliance is pursuing as a whole. As such, it has factually always served as a core part of how the Bytecode Alliance is pursuing its mission, and has always strived to hold itself to the highest standards.
The original announcement of the Bytecode Alliance introduced the term "nanoprocess": a fine-grained unit of composable functionality which gets access to those, and only those, capabilities it needs to serve its purpose. This concept ultimate became the foundation of the WebAssembly Component Model, with WASI as a set of standardized APIs to facilitate communication with outside systems.
From the beginning, Wasmtime has been a key part of driving the vision of the Component Model and WASI forward: the project has consistently spearheaded the implementation of the standards underlying this vision.
To ensure that Wasmtime can serve the purpose of supporting the exploration and realization of new proposals, the maintainers are taking care to keep the code base approachable. Among the more than 1000 papers on Google Scholar to mention Wasmtime as of this writing, a recent meta-study on the use of different runtimes in academic research shows this paying off: as documented in section 6.2 of that paper (and visualized in figure 16 on page 23), 30% of all analyzed papers used Wasmtime as the test bed for research into feature addition, with the next most popular runtime at 17.5%.
Aside from feature work, Wasmtime's well-maintained and approachable code base also helps its maintainers in treating security as a hard requirement that can't be traded off against any other priorities, as described in a post on the Bytecode Alliance blog in 2022.
To further the Bytecode Alliance goal of bringing security, efficiency, and modularity to a wide range of use cases and platforms, Wasmtime is designed to be usable in a diverse set of environments. To satisfy different tradeoffs between peak performance, fast startup, and portability, it integrates three different execution engines:
Combined with the ease of portability that Wasmtime's support for
#![no_std]
environments brings, Wasmtime is portable and usable in environments ranging from small embedded devices to large-scale compute clusters.More details on the various aspects of this can be found in the comments on the other requirements below.
Changelog
The Wasmtime project publishes detailed release notes for all releases, and keeps an up-to-date index of the notes for each release. These notes include lists of notable bug fixes, changes to existing functionality, and newly introduced features or functionality.
Additionally, blog posts covering the releases and highlighting key changes are regularly published to the Bytecode Alliance blog.
Recent examples of changelogs and announcement posts include
Code Review
Wasmtime has a CODEOWNERS file gating all merges, and auto-assigns the @bytecodealliance/wasmtime-core-reviewers team to review PRs.
The review process is highly efficient, with a medium response time of 6 hours over the last year.
Good recent examples of the typical review experience for Wasmtime include
br_table
instruction wasmtime#9659WasmCompositeInnerType
layer wasmtime#9520Code of Conduct
Wasmtime has a CoC file in its repository, and the project takes CoC enforcement very seriously.
Over the years, there have been situations where individuals violated the CoC or skated very close to doing so, and the project has always acted on those instances without delay as soon as maintainers gained awareness of them.
Since it doesn't seem appropriate to call out specific instances of this in a public document, this application doesn't include links to them as evidence. Those can be provided to the TSC in private communication as needed, though.
Continuous Fuzzing
Wasmtime was the first Rust project admitted to OSS-Fuzz, spearheading Rust fuzzing infrastructure. As described in a 2022 blog post, Wasmtime has since gained a rich set of different fuzzers, which are run against all code landing on
main
that's active in the default compile configuration.This catches that vast majority of issues before they become exploitable vulnerabilities, since our release process guarantees at least a 2-week window between code landing on
main
and any release including that code.The fuzzing doesn't just include Wasmtime itself, but also its dependency tree, notably including Cranelift, regalloc2, and wasm-tools. Wasmtime's fuzzing additionally strives to be as comprehensive as possible to go above-and-beyond "just compile the fuzz input as wasm". The Wasmtime project has invested heavily in design patterns for fuzzing in Rust such as the
arbitrary
crate, thewasm-smith
crate, integration with the spec interpreter, etc. Wasmtime's fuzzing includes a large suite of fuzz targets such as:Wasmtime has a large number of configuration knobs and fuzzing does not only cover the default settings of these knobs. Wasmtime's fuzzing will generate arbitrary configurations for an
Engine
to test interesting combinations of settings to ensure that non-default settings work the same as default settings.All of Wasmtime's fuzzing is targetted at testing as much as possible about the WebAssembly sandbox. There are many components to Wasmtime and its runtime and many of them are security critical and all are required to be fuzzed to be considered "tier 1 supported" in Wasmtime. For example aarch64, despite having a high-quality implementation, is not considered "tier 1" in Wasmtime because we don't have continuous fuzzing for it yet.
Continuous Integration Testing
Wasmtime is using GitHub Actions for CI and CD, running extensive test suites and automated builds for all supported configurations and build targets. As of this writing, before changes are merged into the
main
branch, they run through a set of tests and builds for a total of more than 12 hours (within a timeframe of about 16 minutes wall-clock time). As part of this, we generate binary artifacts for all supported platforms and build configurations, and run test suites coveringcargo vet
checks ensuring the security of our supply chainEverything happening in CI is fully public and reproducible by the public, ensuring full auditability by external parties of all code and the entire build process without active support by the project.
Contributor Documentation
Wasmtime's repository contains a CONTRIBUTING.md file, though that mainly links to the contributing section of Wasmtime's online documentation.
That section contains detailed information about how to get started with building and making changes to Wasmtime, how changes are tested, what to expect when making a pull request, recommended guidelines for code an dependencies, which changes would be acceptable, how to engage with the community, etc. Wasmtime also has documentation for maintainers such as review guidelines and how to make a release as part of the same documentation.
End-User Documentation
Wasmtime has extensive online documentation, which is required to keep up-to-date as part of changing the code base. Wherever possible, the correctness of documentation is checked during CI.
The documentation includes among other topics:
The docs don't have a dedicated section for tutorials. Instead, the examples are documented in a way that makes it possible to follow them like tutorials.
Following the Bytecode Alliance Operational Principles
The Wasmtime project takes great care to uphold the standards set out in the BA's Operational Principles. Since the technical and procedural aspects are covered elsewhere in this application, here we want to focus on aspects related to norms we hold ourselves to, and how we engage with the outside world.
A major part of how Wasmtime interacts with other venues is as part of the standardization process of WebAssembly and in particular the Component Model, and WASI. Wasmtime is dedicated both to helping drive innovation in the standards process by spearheading new proposals and implementation techniques, as well as to staying faithful to the standards and consistently staying fully compliant with them.
This means that we invest substantially in engaging with the standards processes and maintain a strong presence and standing in the respective committees, since otherwise we'd not be able to satisify our users' and contributors' requirements. As described in the requirements for enabling features by default
Issue Triage Process
Wasmtime uses GitHub Issues for issue tracking and has a good track record of responsiveness, with the median issue being addressed within 5h. Additionally, the project just introduced a formal triage process as part of the bi-weekly project meetings.
Leverage the Bytecode Alliance RFC Process
Wasmtime employs the RFC process for a wide range of decisions and proposed changes. Examples include among others
Licensing Compatible with the Bytecode Alliance
Wasmtime fully complies with the BA's license requirements. All code in the Wasmtime repository is licensed under the Apache-2.0 WITH LLVM-exception, and all third-party dependencies use licenses on the permitted list.
Ongoing license compliance is ensured in CI using
cargo deny
.Production Use
Wasmtime maintains an ADOPTERS.md which as of this writing lists 10 production uses. Together, these documented uses represent adoption at substantial scale, with Wasmtime being part of processes that many millions of people interact with daily. Besides these formally documented uses, the project is aware of wide-spread additional production use, evidence of which can be provided to the TSC as needed.
Public Project Meetings and Notes
The Wasmtime project hosts a project meeting every other week. The meetings are open to the general public, with the signup process fully documented. Agendas for the meeting are published ahead of time, and meeting notes afterwards—both in the BA's meetings repository.
README
The Wasmtime project's repository contains a detailed top-level README.md satisfying all requirements.
Additionally, many of the crates Wasmtime consists of include their own dedicated
README.md
files, containing information specifically about the crate in question.Release Process
Wasmtime's release process is fully-automated using GitHub Actions, and for stable releases happens from dedicated branches for the respective versions. All released artifacts are fully built using this workflow, which can be fully reproduced (in the sense of being able to run the same process without limitations, not in the sense of "reproducible builds" with bit-identical artifacts) by external parties.
The official releases and the way they are published use GitHub Actions' key management, such that no single individual's participation is required to run the official release process. The release process is started through calendar-based automation by the wasmtime-publish account opening a PR on the Wasmtime repository, which is then approved and merged by a maintainer.
This process is used both for regular stable releases and for patch releases, including those addressing security issues.
Sanitizers and Code Analysis
Wasmtime's implementation language, Rust, is safe by default. Wasmtime has a nontrivial amount of
unsafe
code, however, and expects all unsafe code is thoroughly tested on CI. Integration beyond unit tests at this time is:unsafe
code in the repository.Security Process
Wasmtime uses a carefully designed process for handling vulnerabilities, based on a specific definition of what's considered a vulnerability.
The security advisories published by the project provide a view into how this process has been run over the last few years. The maintainers believe this process to be highly effective at properly and rapidly handling (potential) vulnerabilities.
Additionally, Wasmtime's CI runs a workflow for cargo audit, ensuring that published vulnerabilities in dependencies are noticed right-away.
Semantic Versioning
Wasmtime follows the Rust ecosystem's approach to semantic versioning, with API incompatible changes being limited to major versions. Moreover, since a new major release of Wasmtime is released monthly, maintainers take care to reduce and document breaking changes.
A more detailed description to Wasmtime's approach to versioning can be found in the 1.0 release RFC.
Secrets Management
All secrets required to fully maintain Wasmtime are under organizational control of the Bytecode Alliance, with no individual having ownership over keys required for any aspect of maintenance. For the most part, this is ensured by using GitHub's secrets management.
Supply Chain Security
In addition to following strict procedures for reviewing code and running release processes, wasmtime strictly enforces passing a cargo vet check as part of CI before any code is permitted to land on
main
. Where required, Wasmtime's maintainers will supply audits to permit new (versions of) dependencies. For example, this PR swapped some dependencies and included an audit of the new dependency.Sustainable Contributor Base
Wasmtime regularly receives contributions from people affiliated with dozens of organizations, including multiple Bytecode Alliance member organizations. Over the last 12 months, the project received contributions from 37 individuals (not counting automated accounts), representing at least 20 different organizations.
Core project maintainers are also employed by multiple different Bytecode Alliance member organizations (including Fastly, Fermyon, and Intel), ensuring good ongoing alignment with the BA's mission as well as representation in the wider BA.
Version Control
Wasmtime itself and most of its key dependencies are hosted by the Bytecode Alliance on Github, using
git
. Where dependencies aren't hosted by the BA, they are established parts of the Rust ecosystem.Footnotes
The one exception to this rule is the Component Model, which is fundamentally required for WASI support, and considered stable in the context of its use in WASIp2 and onwards. ↩
The text was updated successfully, but these errors were encountered: