Skip to content

Commit

Permalink
Community project 1/? (openmls#204)
Browse files Browse the repository at this point in the history 
* Add metadata to Cargo.toml

* Add more

* Address review comments

* More changes to make OpenMLS a community project
  • Loading branch information
@raphaelrobert
raphaelrobert authored Nov 11, 2020
1 parent 3105e3c commit 1afb6ef
Show file tree
Hide file tree
Showing 4 changed files with 210 additions and 47 deletions.
1 change: 1 addition & 0 deletions CODEOWNERS
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
* @raphaelrobert @franziskuskiefer
128 changes: 128 additions & 0 deletions CODE_OF_CONDUCT.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,128 @@
# Contributor Covenant Code of Conduct

## Our Pledge

We as members, contributors, and leaders pledge to make participation in our
community a harassment-free experience for everyone, regardless of age, body
size, visible or invisible disability, ethnicity, sex characteristics, gender
identity and expression, level of experience, education, socio-economic status,
nationality, personal appearance, race, religion, or sexual identity
and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming,
diverse, inclusive, and healthy community.

## Our Standards

Examples of behavior that contributes to a positive environment for our
community include:

- Demonstrating empathy and kindness toward other people
- Being respectful of differing opinions, viewpoints, and experiences
- Giving and gracefully accepting constructive feedback
- Accepting responsibility and apologizing to those affected by our mistakes,
and learning from the experience
- Focusing on what is best not just for us as individuals, but for the
overall community

Examples of unacceptable behavior include:

- The use of sexualized language or imagery, and sexual attention or
advances of any kind
- Trolling, insulting or derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others' private information, such as a physical or email
address, without their explicit permission
- Other conduct which could reasonably be considered inappropriate in a
professional setting

## Enforcement Responsibilities

Community leaders are responsible for clarifying and enforcing our standards of
acceptable behavior and will take appropriate and fair corrective action in
response to any behavior that they deem inappropriate, threatening, offensive,
or harmful.

Community leaders have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, and will communicate reasons for moderation
decisions when appropriate.

## Scope

This Code of Conduct applies within all community spaces, and also applies when
an individual is officially representing the community in public spaces.
Examples of representing our community include using an official e-mail address,
posting via an official social media account, or acting as an appointed
representative at an online or offline event.

## Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported to the community leaders responsible for enforcement at
[TBD].
All complaints will be reviewed and investigated promptly and fairly.

All community leaders are obligated to respect the privacy and security of the
reporter of any incident.

## Enforcement Guidelines

Community leaders will follow these Community Impact Guidelines in determining
the consequences for any action they deem in violation of this Code of Conduct:

### 1. Correction

**Community Impact**: Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.

**Consequence**: A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behavior was inappropriate. A public apology may be requested.

### 2. Warning

**Community Impact**: A violation through a single incident or series
of actions.

**Consequence**: A warning with consequences for continued behavior. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external channels
like social media. Violating these terms may lead to a temporary or
permanent ban.

### 3. Temporary Ban

**Community Impact**: A serious violation of community standards, including
sustained inappropriate behavior.

**Consequence**: A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public or
private interaction with the people involved, including unsolicited interaction
with those enforcing the Code of Conduct, is allowed during this period.
Violating these terms may lead to a permanent ban.

### 4. Permanent Ban

**Community Impact**: Demonstrating a pattern of violation of community
standards, including sustained inappropriate behavior, harassment of an
individual, or aggression toward or disparagement of classes of individuals.

**Consequence**: A permanent ban from any sort of public interaction within
the community.

## Attribution

This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 2.0, available at
https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.

Community Impact Guidelines were inspired by [Mozilla's code of conduct
enforcement ladder](https://github.com/mozilla/diversity).

[homepage]: https://www.contributor-covenant.org

For answers to common questions about this code of conduct, see the FAQ at
https://www.contributor-covenant.org/faq. Translations are available at
https://www.contributor-covenant.org/translations.
101 changes: 56 additions & 45 deletions CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,10 @@ These are mostly guidelines, not rules.
Use your best judgement, and feel free to propose changes to this document in a pull request.
The processes described here is not to pester you but to increase and maintain code quality.

Before contributing, please read the [Code of Conduct](https://github.com/openmls/openmls/CODE_OF_CONDUCT.md) carefully.

#### Table Of Contents

- [Working with this repository](#working-with-this-repository)
- [Prioritisation](#prioritisation)
- [Pull Requests](#pull-requests)
Expand All @@ -19,6 +22,7 @@ The processes described here is not to pester you but to increase and maintain c
- [Review Guidelines](#review-guidelines)

## Working with this repository

We use issues to organise and prioritise work items.
If you start working on an issue, assign it to yourself so everyone knows it's being worked on.
Unassign yourself if you stop working on it and leave a comment why you stopped.
Expand All @@ -30,6 +34,7 @@ There must be one pull request that closes the issue.
If there are multiple PRs for an issue, make sure this is clear in the pull request.

### Prioritisation

Issue priorities are reflected with labels.

| Label | Description |
Expand All @@ -47,72 +52,78 @@ The changeset in a pull requests must not be larger than 1000 lines.
If an issue needs more work than that, split it into multiple pull requests.

Make sure that your PR follows the [template](#pr-template).
After submitting the pull request, verify that all [status checks](https://help.github.com/articles/about-status-checks/) are passing before asking for review.
After submitting the pull request, verify that all [status checks](https://help.github.com/articles/about-status-checks/) are passing before asking for review.

While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.

### PR & Commit Guidelines
* Split out mass-changes or mechanical changes into a separate PR from the substantive changes.
* Separate commits into conceptually-separate pieces for review purposes (even if you then later collapse them into a single changeset to merge), if technically possible.
* Address all comments from previous reviews (either by fixing as requested, or explaining why you haven't) before requesting another review.
* If your request only relates to part of the changes, say so clearly.

- Split out mass-changes or mechanical changes into a separate PR from the substantive changes.
- Separate commits into conceptually-separate pieces for review purposes (even if you then later collapse them into a single changeset to merge), if technically possible.
- Address all comments from previous reviews (either by fixing as requested, or explaining why you haven't) before requesting another review.
- If your request only relates to part of the changes, say so clearly.

### PR Template
* Link to an open issue and assign yourself to the issue and the PR (if possible).
* It must be possible to understand the design of your change from the description. If it's not possible to get a good idea of what the code will be doing from the description here, the pull request may be closed. Keep in mind that the reviewer may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
* Explain what other alternates were considered and why the proposed version was selected.
* What are the possible side-effects or negative impacts of the code change?
* What process did you follow to verify that your change has the desired effects?
* How did you verify that all new functionality works as expected?
* How did you verify that all changed functionality works as expected?
* How did you verify that the change has not introduced any regressions?
* Describe the actions you performed (including buttons you clicked, text you typed, commands you ran, etc.), and describe the results you observed.
* If this is a user-facing change please describe the changes in a single line that explains this improvement in terms that a library user can understand.

- Link to an open issue and assign yourself to the issue and the PR (if possible).
- It must be possible to understand the design of your change from the description. If it's not possible to get a good idea of what the code will be doing from the description here, the pull request may be closed. Keep in mind that the reviewer may not be familiar with or have worked with the code here recently, so please walk us through the concepts.
- Explain what other alternates were considered and why the proposed version was selected.
- What are the possible side-effects or negative impacts of the code change?
- What process did you follow to verify that your change has the desired effects?
- How did you verify that all new functionality works as expected?
- How did you verify that all changed functionality works as expected?
- How did you verify that the change has not introduced any regressions?
- Describe the actions you performed (including buttons you clicked, text you typed, commands you ran, etc.), and describe the results you observed.
- If this is a user-facing change please describe the changes in a single line that explains this improvement in terms that a library user can understand.

## Styleguides

### Git Commit Messages

* Use the present tense
* Use the imperative mood
* Limit the first line to 80 characters
* Reference issues and pull requests liberally after the first line
* If the patch is of nontrivial size, point to the important comments in the non-first lines of the commit message.
- Use the present tense
- Use the imperative mood
- Limit the first line to 80 characters
- Reference issues and pull requests liberally after the first line
- If the patch is of nontrivial size, point to the important comments in the non-first lines of the commit message.

### Rust Styleguide

Use `rustfmt` on everything.
The CI will check that the patch adheres to the `rustfmt` style.

### Documentation Styleguide

Use [rustdoc](https://doc.rust-lang.org/rustdoc/index.html) comments on files and functions.
It is mandatory on public functions and encouraged on internal functions.

## Reviews

As a reviewer always keep in mind the following principles

* Reviewing code is more valuable than writing code as it results in higher overall project activity. If you find you can't write code any more due to prioritizing reviews over coding, let's talk.
* You should respond to a review request within one working day of getting it, either with a review, a deadline by which you promise to do the review, or a polite refusal. If you think a patch is lower priority than your other work communicate that.
- Reviewing code is more valuable than writing code as it results in higher overall project activity. If you find you can't write code any more due to prioritizing reviews over coding, let's talk.
- You should respond to a review request within one working day of getting it, either with a review, a deadline by which you promise to do the review, or a polite refusal. If you think a patch is lower priority than your other work communicate that.

### Review Guidelines
* Check that issue is assigned and linked.
* Commit title and message make sense and says what is being changed.
* Check that the PR applies cleanly on the target branch.
* Check new files for license and administrative issues.
* Check out code changes
* Run automated tests
* Manually verify changes if possible
* Code review
* Does the change address the issue at hand?
* Is the code well documented?
* Do you understand the code changes?
* If not, add a comment. The PR can't be accepted in this stage.
* Is the public API changed?
* Are the changes well documented for consumers?
* Do the changes break backwards compatibility?
* Is the new API sensible/needed?
* Is the code maintainable after these changes?
* Are there any security issues with these changes?
* Are all code changes tested?
* Do the changes affect performance?
* Look at the interdiff for second and subsequent reviews.
* Ask if more information is needed to understand and judge the changes.

- Check that issue is assigned and linked.
- Commit title and message make sense and says what is being changed.
- Check that the PR applies cleanly on the target branch.
- Check new files for license and administrative issues.
- Check out code changes
- Run automated tests
- Manually verify changes if possible
- Code review
- Does the change address the issue at hand?
- Is the code well documented?
- Do you understand the code changes?
- If not, add a comment. The PR can't be accepted in this stage.
- Is the public API changed?
- Are the changes well documented for consumers?
- Do the changes break backwards compatibility?
- Is the new API sensible/needed?
- Is the code maintainable after these changes?
- Are there any security issues with these changes?
- Are all code changes tested?
- Do the changes affect performance?
- Look at the interdiff for second and subsequent reviews.
- Ask if more information is needed to understand and judge the changes.
27 changes: 25 additions & 2 deletions README.md
View file
Original file line number Diff line number Diff line change
@@ -1,15 +1,26 @@
# openmls
# OpenMLS

![build status](https://travis-ci.com/openmls/openmls.svg?branch=main)

This is a WIP Rust implementation of [Messaging Layer Security](https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md) based on draft 9+.
A WIP Rust implementation of [Messaging Layer Security](https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md) based on draft 9+.

### Supported ciphersuites

- MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 (MTI)
- MLS10_128_DHKEMP256_AES128GCM_SHA256_P256
- MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519

### Supported platforms

- linux x86_64
- linux arm32
- linux arm64
- macOS x86_64

### Dependencies

OpenMLS relies on [EverCrypt](https://github.com/project-everest/hacl-star/tree/master/providers/evercrypt), a high-performance, cross-platform, formally verified modern cryptographic provider through [EverCrypt Rust bindings](https://crates.io/crates/evercrypt).

## Build

- run `cargo build`
Expand All @@ -21,3 +32,15 @@ This is a WIP Rust implementation of [Messaging Layer Security](https://github.c
## Benchmark

- run `cargo bench`

## License

OpenMLS is licensed under the MIT license. The license can be found [here](https://github.com/openmls/openmls/LICENSE).

## Contributing

Open MLS welcomes contributions! Before contributing, please read the [contributing guidelines[(https://github.com/openmls/openmls/CONTRIBUTING.md)] carefully.

## Code of conduct

Open MLS adheres to the [Contributor Covenant[(https://www.contributor-covenant.org/)] Code of Coduct. Please read the [Code of Conduct](https://github.com/openmls/openmls/CODE_OF_CONDUCT.md) carefully.

0 comments on commit 1afb6ef

Please sign in to comment.