From 35d38f9b3c8671ecd1cff7c00c8daf984f486ac3 Mon Sep 17 00:00:00 2001 From: Chris Woods Date: Thu, 16 Jul 2026 13:52:50 -0400 Subject: [PATCH 1/7] Removed BA references --- ORG_CODE_OF_CONDUCT.md | 139 ----------------------------------------- TSC_Charter.md | 113 ++++++++++++++------------------- 2 files changed, 48 insertions(+), 204 deletions(-) delete mode 100644 ORG_CODE_OF_CONDUCT.md diff --git a/ORG_CODE_OF_CONDUCT.md b/ORG_CODE_OF_CONDUCT.md deleted file mode 100644 index e05e40c3c4..0000000000 --- a/ORG_CODE_OF_CONDUCT.md +++ /dev/null @@ -1,139 +0,0 @@ -# Bytecode Alliance Organizational Code of Conduct (OCoC) - -*Note*: this Code of Conduct pertains to organizations' behavior. Please also see the [Individual Code of Conduct](CODE_OF_CONDUCT.md). - -## Preamble - -The Bytecode Alliance (BA) welcomes involvement from organizations, -including commercial organizations. This document is an -*organizational* code of conduct, intended particularly to provide -guidance to commercial organizations. It is distinct from the -[Individual Code of Conduct (ICoC)](CODE_OF_CONDUCT.md), and does not -replace the ICoC. This OCoC applies to any group of people acting in -concert as a BA member or as a participant in BA activities, whether -or not that group is formally incorporated in some jurisdiction. - -The code of conduct described below is not a set of rigid rules, and -we did not write it to encompass every conceivable scenario that might -arise. For example, it is theoretically possible there would be times -when asserting patents is in the best interest of the BA community as -a whole. In such instances, consult with the BA, strive for -consensus, and interpret these rules with an intent that is generous -to the community the BA serves. - -While we may revise these guidelines from time to time based on -real-world experience, overall they are based on a simple principle: - -*Bytecode Alliance members should observe the distinction between - public community functions and private functions — especially - commercial ones — and should ensure that the latter support, or at - least do not harm, the former.* - -## Guidelines - - * **Do not cause confusion about Wasm standards or interoperability.** - - Having an interoperable WebAssembly core is a high priority for - the BA, and members should strive to preserve that core. It is fine - to develop additional non-standard features or APIs, but they - should always be clearly distinguished from the core interoperable - Wasm. - - Treat the WebAssembly name and any BA-associated names with - respect, and follow BA trademark and branding guidelines. If you - distribute a customized version of software originally produced by - the BA, or if you build a product or service using BA-derived - software, use names that clearly distinguish your work from the - original. (You should still provide proper attribution to the - original, of course, wherever such attribution would normally be - given.) - - Further, do not use the WebAssembly name or BA-associated names in - other public namespaces in ways that could cause confusion, e.g., - in company names, names of commercial service offerings, domain - names, publicly-visible social media accounts or online service - accounts, etc. It may sometimes be reasonable, however, to - register such a name in a new namespace and then immediately donate - control of that account to the BA, because that would help the project - maintain its identity. - - * **Do not restrict contributors.** If your company requires - employees or contractors to sign non-compete agreements, those - agreements must not prevent people from participating in the BA or - contributing to related projects. - - This does not mean that all non-compete agreements are incompatible - with this code of conduct. For example, a company may restrict an - employee's ability to solicit the company's customers. However, an - agreement must not block any form of technical or social - participation in BA activities, including but not limited to the - implementation of particular features. - - The accumulation of experience and expertise in individual persons, - who are ultimately free to direct their energy and attention as - they decide, is one of the most important drivers of progress in - open source projects. A company that limits this freedom may hinder - the success of the BA's efforts. - - * **Do not use patents as offensive weapons.** If any BA participant - prevents the adoption or development of BA technologies by - asserting its patents, that undermines the purpose of the - coalition. The collaboration fostered by the BA cannot include - members who act to undermine its work. - - * **Practice responsible disclosure** for security vulnerabilities. - Use designated, non-public reporting channels to disclose technical - vulnerabilities, and give the project a reasonable period to - respond, remediate, and patch. - - Vulnerability reporters may patch their company's own offerings, as - long as that patching does not significantly delay the reporting of - the vulnerability. Vulnerability information should never be used - for unilateral commercial advantage. Vendors may legitimately - compete on the speed and reliability with which they deploy - security fixes, but withholding vulnerability information damages - everyone in the long run by risking harm to the BA project's - reputation and to the security of all users. - - * **Respect the letter and spirit of open source practice.** While - there is not space to list here all possible aspects of standard - open source practice, some examples will help show what we mean: - - * Abide by all applicable open source license terms. Do not engage - in copyright violation or misattribution of any kind. - - * Do not claim others' ideas or designs as your own. - - * When others engage in publicly visible work (e.g., an upcoming - demo that is coordinated in a public issue tracker), do not - unilaterally announce early releases or early demonstrations of - that work ahead of their schedule in order to secure private - advantage (such as marketplace advantage) for yourself. - - The BA reserves the right to determine what constitutes good open - source practices and to take action as it deems appropriate to - encourage, and if necessary enforce, such practices. - -## Enforcement - -Instances of organizational behavior in violation of the OCoC may -be reported by contacting the Bytecode Alliance CoC team at -[report@bytecodealliance.org](mailto:report@bytecodealliance.org). The -CoC team will review and investigate all complaints, and will respond -in a way that it deems appropriate to the circumstances. The CoC team -is obligated to maintain confidentiality with regard to the reporter of -an incident. Further details of specific enforcement policies may be -posted separately. - -When the BA deems an organization in violation of this OCoC, the BA -will, at its sole discretion, determine what action to take. The BA -will decide what type, degree, and duration of corrective action is -needed, if any, before a violating organization can be considered for -membership (if it was not already a member) or can have its membership -reinstated (if it was a member and the BA canceled its membership due -to the violation). - -In practice, the BA's first approach will be to start a conversation, -with punitive enforcement used only as a last resort. Violations -often turn out to be unintentional and swiftly correctable with all -parties acting in good faith. diff --git a/TSC_Charter.md b/TSC_Charter.md index 56c4a024b9..30f9782fcc 100644 --- a/TSC_Charter.md +++ b/TSC_Charter.md @@ -1,64 +1,50 @@ -# Project Technical Steering Committee (PTSC) Charter +# WAMR Technical Steering Committee (WAMR-TSC) Charter ## Section 1. Guiding Principle -The WebAssembly Micro Runtime (WAMR) project is part of the -Bytecode Alliance (BA) which operates transparently, openly, +The WebAssembly Micro Runtime (WAMR) project aims to operate transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders. -## Section 2. Project Governance under Bytecode Alliance +## Section 2. Project Governance -Technical leadership for the WAMR projects within the Bytecode Alliance -is delegated to the projects through the project charter. Though the BA TSC -will not interfere with day-to-day discussions, votes or meetings of the PTSC, -the BA TSC may request additional amendments to the PTSC charter when -there is misalignment between the project charter and the BA mission and values. +The WAMR-TSC structure described in this document may be updated as part of the +WAMR projects evolution. +## Section 3. Establishment of the WAMR-TSC - -The PTSC structure described in this document may be overhauled as part of -establishing a BA TSC in order to adhere to constraints or requirements that -TSC will impose on project-level governance. - -## Section 3. Establishment of the PTSC - -PTSC memberships are not time-limited. There is no maximum size of the PTSC. +WAMR-TSC memberships are not time-limited. There is no maximum size of the WAMR-TSC. The size is expected to vary in order to ensure adequate coverage of important areas of expertise, balanced with the ability to make decisions efficiently. -The PTSC must have at least four members. +The WAMR-TSC must have at least four members. -There is no specific set of requirements or qualifications for PTSC -membership beyond these rules. The PTSC may add additional members to the -PTSC by a standard PTSC motion and vote. A PTSC member may be removed from the -PTSC by voluntary resignation, by a standard PTSC motion, or in accordance to the +There is no specific set of requirements or qualifications for WAMR-TSC +membership beyond these rules. The WAMR-TSC may add additional members to the +WAMR-TSC by a standard WAMR-TSC motion and vote. A WAMR-TSC member may be removed from the +WAMR-TSC by voluntary resignation, by a standard WAMR-TSC motion, or in accordance to the participation rules described below. -Changes to PTSC membership should be posted in the agenda, and may be suggested +Changes to WAMR-TSC membership should be posted in the agenda, and may be suggested as any other agenda item. -The PTSC may, at its discretion, invite any number of non-voting observers to -participate in the public portion of PTSC discussions and meetings. +The WAMR-TSC may, at its discretion, invite any number of non-voting observers to +participate in the public portion of WAMR-TSC discussions and meetings. -The PTSC shall meet regularly using tools that enable participation by the -community (e.g. weekly on a Zulip channel, or through any other -appropriate means selected by the PTSC ). The meeting shall be directed by -the PTSC Chairperson. Responsibility for directing individual meetings may be -delegated by the PTSC Chairperson to any other PTSC member. Minutes or an -appropriate recording shall be taken and made available to the community +The WAMR-TSC shall meet regularly using tools that enable participation by the +community. The meeting shall be directed by the WAMR-TSC Chairperson. Responsibility for directing individual meetings may be delegated by the WAMR-TSC Chairperson to any other WAMR-TSC member. Minutes or an appropriate recording shall be taken and made available to the community through accessible public postings. -PTSC members are expected to regularly participate in PTSC activities. +WAMR-TSC members are expected to regularly participate in WAMR-TSC activities. -In the case where an individual PTSC member -- within any three month period -- +In the case where an individual WAMR-TSC member -- within any three month period -- attends fewer than 25% of the regularly scheduled meetings, does not -participate in PTSC discussions, *and* does not participate in PTSC votes, the -member shall be automatically removed from the PTSC. The member may be invited -to continue attending PTSC meetings as an observer. +participate in WAMR-TSC discussions, *and* does not participate in WAMR-TSC votes, the +member shall be automatically removed from the WAMR-TSC. The member may be invited +to continue attending WAMR-TSC meetings as an observer. -## Section 4. Responsibilities of the PTSC +## Section 4. Responsibilities of the WAMR-TSC -Subject to such policies as may be set by the BA TSC, the WAMR PTSC is +Subject to such policies as may be set by the BA TSC, the WAMR WAMR-TSC is responsible for all technical development within the WAMR project, including: @@ -73,27 +59,24 @@ including: * Mediating technical conflicts between Collaborators or Foundation projects. -The PTSC will define WAMR project’s release vehicles. +The WAMR-TSC will define WAMR project’s release vehicles. ## Section 5. WAMR Project Operations -The PTSC will establish and maintain a development process for the WAMR +The WAMR-TSC will establish and maintain a development process for the WAMR project. The development process will establish guidelines for how the developers and community will operate. It will, for example, -establish appropriate timelines for PTSC review (e.g. agenda items must be -published at least a certain number of hours in advance of a PTSC +establish appropriate timelines for WAMR-TSC review (e.g. agenda items must be +published at least a certain number of hours in advance of a WAMR-TSC meeting). -The PTSC and entire technical community will follow any processes as may -be specified by the Bytecode Alliance Board relating to the intake and license compliance -review of contributions, including the Bytecode Alliance IP Policy. ## Section 6. Elections Leadership roles in the WAMR project will be peer elected representatives of the community. -For election of persons (such as the PTSC Chairperson), a multiple-candidate +For election of persons (such as the WAMR-TSC Chairperson), a multiple-candidate method should be used, such as: * [Condorcet][] or @@ -105,47 +88,47 @@ election is required if there is only one candidate and no objections to the candidate's election. Elections shall be done within the projects by the Collaborators active in the project. -The PTSC will elect from amongst voting PTSC members a PTSC Chairperson to -work on building an agenda for PTSC meetings. The PTSC shall hold annual +The WAMR-TSC will elect from amongst voting WAMR-TSC members a WAMR-TSC Chairperson to +work on building an agenda for WAMR-TSC meetings. The WAMR-TSC shall hold annual -elections to select a PTSC Chairperson; there are no limits on the number -of terms a PTSC Chairperson may serve. +elections to select a WAMR-TSC Chairperson; there are no limits on the number +of terms a WAMR-TSC Chairperson may serve. ## Section 7. Voting For internal project decisions, Collaborators shall operate under Lazy -Consensus. The PTSC shall establish appropriate guidelines for +Consensus. The WAMR-TSC shall establish appropriate guidelines for implementing Lazy Consensus (e.g. expected notification and review time periods) within the development process. -The PTSC follows a [Consensus Seeking][] decision making model. When an agenda +The WAMR-TSC follows a [Consensus Seeking][] decision making model. When an agenda item has appeared to reach a consensus the moderator will ask "Does anyone object?" as a final call for dissent from the consensus. -If an agenda item cannot reach a consensus a PTSC member can call for +If an agenda item cannot reach a consensus a WAMR-TSC member can call for either a closing vote or a vote to table the issue to the next meeting. -The call for a vote must be seconded by a majority of the PTSC or else the +The call for a vote must be seconded by a majority of the WAMR-TSC or else the discussion will continue. -For all votes, a simple majority of all PTSC members for, or against, the issue -wins. A PTSC member may choose to participate in any vote through abstention. +For all votes, a simple majority of all WAMR-TSC members for, or against, the issue +wins. A WAMR-TSC member may choose to participate in any vote through abstention. ## Section 8. Project Roles -The WAMR git repository is maintained by the PTSC and -additional Collaborators who are added by the PTSC on an ongoing basis. +The WAMR git repository is maintained by the WAMR-TSC and +additional Collaborators who are added by the WAMR-TSC on an ongoing basis. Individuals making significant and valuable contributions, “Contributor(s)”, are made Collaborators and given commit-access to the -project. These individuals are identified by the PTSC and their addition -as Collaborators is discussed during a PTSC meeting. Modifications of the +project. These individuals are identified by the WAMR-TSC and their addition +as Collaborators is discussed during a WAMR-TSC meeting. Modifications of the contents of the git repository are made on a collaborative basis as defined in the development process. Collaborators may opt to elevate significant or controversial -modifications, or modifications that have not found consensus to the PTSC +modifications, or modifications that have not found consensus to the WAMR-TSC for discussion by assigning the `tsc-agenda` tag to a pull request or -issue. The PTSC should serve as the final arbiter where required. The PTSC +issue. The WAMR-TSC should serve as the final arbiter where required. The WAMR-TSC will maintain and publish a list of current Collaborators, as well as a development process guide for Collaborators and Contributors looking to participate in the development effort. @@ -155,12 +138,12 @@ looking to participate in the development effort. * **Contributors**: contribute code or other artifacts, but do not have the right to commit to the code base. Contributors work with the project’s Collaborators to have code committed to the code base. A -Contributor may be promoted to a Collaborator by the PTSC. Contributors should -rarely be encumbered by the PTSC. +Contributor may be promoted to a Collaborator by the WAMR-TSC. Contributors should +rarely be encumbered by the WAMR-TSC. * **Project**: a technical collaboration effort, e.g. a subsystem, that is organized through the project creation process and approved by the -PTSC. +WAMR-TSC. [Consensus Seeking]: https://en.wikipedia.org/wiki/Consensus-seeking_decision-making [Condorcet]: https://en.wikipedia.org/wiki/Condorcet_method From aee758eab386943049e865541d2492962cd09411 Mon Sep 17 00:00:00 2001 From: Chris Woods Date: Thu, 16 Jul 2026 13:54:46 -0400 Subject: [PATCH 2/7] Removing reference to BA and OCOC --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4382257321..ba176a1ce3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -40,4 +40,4 @@ We use GitHub issues to track public bugs. Report a bug by [open a new issue](ht Code of Conduct =============== -WAMR is a [Bytecode Alliance](https://bytecodealliance.org/) project, and follows the Bytecode Alliance's [Code of Conduct](CODE_OF_CONDUCT.md) and [Organizational Code of Conduct](ORG_CODE_OF_CONDUCT.md). +WAMR follows its own [Code of conduct](CODE_OF_CONDUCT.md). From 3bebc09530ec537190e22c8ccd14d51f30c17e79 Mon Sep 17 00:00:00 2001 From: Chris Woods Date: Thu, 23 Jul 2026 10:09:47 -0400 Subject: [PATCH 3/7] removing mentions of Bytecode Alliance --- README.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/README.md b/README.md index 9d79661c8f..4ac24720fc 100644 --- a/README.md +++ b/README.md @@ -1,11 +1,7 @@ # WebAssembly Micro Runtime -**A [Bytecode Alliance][BA] project** - -[BA]: https://bytecodealliance.org/ - -**[Guide](https://wamr.gitbook.io/)**  **[Website](https://bytecodealliance.github.io/wamr.dev)**  **[Chat](https://bytecodealliance.zulipchat.com/#narrow/stream/290350-wamr)** +**[Guide](https://wamr.gitbook.io/)**  **[Website](https://bytecodealliance.github.io/wamr.dev)** [Build WAMR](./doc/build_wamr.md) | [Build AOT Compiler](./wamr-compiler/README.md) | [Embed WAMR](./doc/embed_wamr.md) | [Export Native API](./doc/export_native_api.md) | [Build Wasm Apps](./doc/build_wasm_app.md) | [Samples](./samples/README.md) From c9c848a9f619118253ee167e7291d97d6de255b9 Mon Sep 17 00:00:00 2001 From: Chris Woods Date: Thu, 23 Jul 2026 10:11:00 -0400 Subject: [PATCH 4/7] removing mentions of Bytecode Alliance --- gitbook/home_page.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gitbook/home_page.md b/gitbook/home_page.md index 831c167f01..24b15371ca 100644 --- a/gitbook/home_page.md +++ b/gitbook/home_page.md @@ -1,6 +1,6 @@ # Welcome -Welcome to the home page of WAMR documentation, [WebAssembly Micro Runtime](https://github.com/bytecodealliance/wasm-micro-runtime) is an open-source project under [Bytecode Alliance](https://bytecodealliance.org/). As the name suggests, it is a lightweight standalone WebAssembly (WASM) runtime with a small footprint, high performance, and highly configurable features for applications across from embedded, IoT, edge Trusted Execution Environment (TEE), smart contract, cloud-native, and so on. +Welcome to the home page of WAMR documentation, [WebAssembly Micro Runtime](https://github.com/bytecodealliance/wasm-micro-runtime) is an open-source project. As the name suggests, it is a lightweight standalone WebAssembly (WASM) runtime with a small footprint, high performance, and highly configurable features for applications across from embedded, IoT, edge Trusted Execution Environment (TEE), smart contract, cloud-native, and so on. ## How to navigate the documentation From 68c04757cfe976f472ca342a5ea16c05d808aa5a Mon Sep 17 00:00:00 2001 From: Chris Woods Date: Thu, 23 Jul 2026 10:12:27 -0400 Subject: [PATCH 5/7] removing references to Bytecode Alliance --- gitbook/basics/introduction/wamr_project.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gitbook/basics/introduction/wamr_project.md b/gitbook/basics/introduction/wamr_project.md index 0cba5b084c..e484fdbca5 100644 --- a/gitbook/basics/introduction/wamr_project.md +++ b/gitbook/basics/introduction/wamr_project.md @@ -4,7 +4,7 @@ ## What is it? -WebAssembly Micro Runtime (WAMR) is a [Bytecode Alliance](https://bytecodealliance.org/) project. A lightweight standalone WebAssembly (WASM) runtime with a small footprint, high performance, and highly configurable features for applications across from embedded, IoT, edge to Trusted Execution Environment (TEE), smart contract, cloud-native, and so on. +WebAssembly Micro Runtime (WAMR) is a lightweight standalone WebAssembly (WASM) runtime. It has a small footprint, high performance, and highly configurable features for applications across from embedded, IoT, edge to Trusted Execution Environment (TEE), smart contract, cloud-native, and so on. ## Why you may want to use it From f8dcf38d354409c22bd49fb692e698c6683b8e42 Mon Sep 17 00:00:00 2001 From: Chris Woods Date: Thu, 23 Jul 2026 10:24:52 -0400 Subject: [PATCH 6/7] Removing references to Bytecode Alliance, and organizational code of conduct --- CODE_OF_CONDUCT.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 5c5ebdd259..8dbfb8ffe3 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,7 +1,5 @@ # Contributor Covenant Code of Conduct -*Note*: this Code of Conduct pertains to individuals' behavior. Please also see the [Organizational Code of Conduct][OCoC]. - ## Our Pledge In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. @@ -36,14 +34,12 @@ This Code of Conduct applies both within project spaces and in public spaces whe ## Enforcement -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the Bytecode Alliance CoC team at [report@bytecodealliance.org](mailto:report@bytecodealliance.org). The CoC team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The CoC team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the WAMR Core team at [wamr-core@googlegroups.com](mailto:wamr-core@googlegroups.com). The core team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The core team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. -Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the Bytecode Alliance's leadership. ## Attribution This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version] -[OCoC]: ORG_CODE_OF_CONDUCT.md [homepage]: https://www.contributor-covenant.org [version]: https://www.contributor-covenant.org/version/1/4/ From aee23b25b972a3f31789ae879d8a55d17cd2d7f2 Mon Sep 17 00:00:00 2001 From: Chris Woods Date: Thu, 23 Jul 2026 10:36:56 -0400 Subject: [PATCH 7/7] inheriting the same security practices as Bytecode Alliance --- SECURITY.md | 41 +++++++++++++++++++++++++++++++++++- doc/security_need_to_know.md | 2 +- 2 files changed, 41 insertions(+), 2 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index fa3398cdec..32e776481b 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,3 +1,42 @@ # Security Policy -Please refer to the [Bytecode Alliance security policy](https://bytecodealliance.org/security) for details on how to report security issues in WebAssembly Micro Runtime, our disclosure policy, and how to receive notifications about security issues. +## Reporting a security bug in a the WAMR Project +Security is a top priority for the WAMR Project. As such, we take all reports of suspected security vulnerabilities seriously, and have a number of ways to report them. + +For suspected vulnerabilities in a specific project, prefer to report the issue using GitHub’s [private vulnerability reporting facilities](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability). Maintainers will then work with you to resolve the issue. + +If you think that that channel isn’t right for reporting your specific issue, you can also send email to the WAMR core team directly via [wamr-core@googlegroups.com](mailto:wamr-core@googlegroups.com). We will then acknowledge receipt of your report and prioritize initial analysis of severity. + +The security team may work in private with individuals from the WAMR Core team, supporting WAMR organizations, core contributors to the affected project, and, where applicable, affected downstream projects and products. + +After the initial reply to your report, the core team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue. + +If you have not received a reply to your report within two days, please reach out again via our email address : [wamr-core@googlegroups.com](mailto:wamr-core@googlegroups.com) + + +## Preferences +* Please provide detailed reports with reproducible steps and a clearly defined impact. +* Submit one vulnerability per report. +* Social engineering (e.g. phishing, vishing, smishing) is prohibited. + +## Disclosure Policy +* The security report is received and is assigned a primary handler. This person will coordinate the fix and release process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not committed to the public repository but rather held locally pending the announcement. + +* A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®)) is requested for the vulnerability. + +* A prenotification may be published on the wamr-dev mailing list, providing information about affected projects, severity, and the embargo date. + +* On the embargo date, the wamr-dev mailing list is sent a copy of the announcement. The changes are pushed to the public repository and new builds are deployed. + +* Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix. + +* This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible; however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner. + +* Core team members are encouraged to write a post-mortem for the WAMR blog, detailing the vulnerability and steps being taken to identify and prevent similar vulnerabilities in the future. + +## Receiving Security Updates +Security notifications will be distributed our wamr-dev email list. Please do join this here: +[https://groups.google.com/g/wamr-dev](https://groups.google.com/g/wamr-dev). + + + diff --git a/doc/security_need_to_know.md b/doc/security_need_to_know.md index e9bc890396..ecf4982377 100644 --- a/doc/security_need_to_know.md +++ b/doc/security_need_to_know.md @@ -62,7 +62,7 @@ Once a maintainer realizes an issue or PR describes a real or possible security ## reporting a security issue -Follow the [same guidelines](https://bytecodealliance.org/security) as other projects within the Bytecode Alliance. +Follow the [security guidelines](../SECURITY.md) to report an issue. ## managing a security issue