Till Schneidereit
5 years ago
committed by
Dan Gohman
Dan Gohman
5 changed files with 189 additions and 6 deletions
@ -1,8 +1,13 @@ |
|||
# Contributing to Wasmtime |
|||
|
|||
Wasmtime follows the same development style as Cranelift, so checkout |
|||
Wasmtime is a [Bytecode Alliance] project, and follows the Bytecode Alliance's [Code of Conduct] and [Organizational Code of Conduct]. |
|||
|
|||
Wasmtime follows the same development style as Cranelift, so check out |
|||
[Cranelift's CONTRIBUTING.md]. Of course, for Wasmtime-specific issues, please |
|||
use the [Wasmtime issue tracker]. |
|||
|
|||
[Bytecode Alliance] : https://bytecodealliance.org/ |
|||
[Code of Conduct] : CODE_OF_CONDUCT.md |
|||
[Organizational Code of Conduct] : ORG_CODE_OF_CONDUCT.md |
|||
[Cranelift's CONTRIBUTING.md]: https://github.com/CraneStation/cranelift/blob/master/CONTRIBUTING.md |
|||
[Wasmtime issue tracker]: https://github.com/CraneStation/wasmtime/issues/new |
|||
|
|||
@ -0,0 +1,143 @@ |
|||
# 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. |
|||
|
|||
For further guidance, see the BA Trademark and Branding Policy |
|||
[TODO: create policy, then insert link]. |
|||
|
|||
* **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. [TODO: optionally include the |
|||
security vulnerability reporting URL here.] |
|||
|
|||
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. |
|||
@ -0,0 +1,29 @@ |
|||
# Security Policy |
|||
|
|||
Building secure foundations for software development is at the core of what we do in the Bytecode Alliance. Contributions of external security researchers are a vital part of that. |
|||
|
|||
## Scope |
|||
|
|||
If you believe you've found a security issue in any website, service, or software owned or operated by the Bytecode Alliance, we encourage you to notify us. |
|||
|
|||
## How to Submit a Report |
|||
|
|||
To submit a vulnerability report to the Bytecode Alliance, please contact us at [security@bytecodealliance.org](mailto:security@bytecodealliance.org). Your submission will be reviewed and validated by a member of our security team. |
|||
|
|||
## Safe Harbor |
|||
|
|||
The Bytecode Alliance supports safe harbor for security researchers who: |
|||
|
|||
* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our services. |
|||
* Only interact with accounts you own or with explicit permission of the account holder. If you do encounter Personally Identifiable Information (PII) contact us immediately, do not proceed with access, and immediately purge any local information. |
|||
* Provide us with a reasonable amount of time to resolve vulnerabilities prior to any disclosure to the public or a third-party. |
|||
|
|||
We will consider activities conducted consistent with this policy to constitute "authorized" conduct and will not pursue civil action or initiate a complaint to law enforcement. We will help to the extent we can if legal action is initiated by a third party against you. |
|||
|
|||
Please submit a report to us before engaging in conduct that may be inconsistent with or unaddressed by this policy. |
|||
|
|||
## 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. |
|||
Loading…
Reference in new issue