OpenSSL

Cryptography and SSL/TLS Toolkit

Guidelines for OpenSSL Committers

Who is a committer?

OpenSSL committers are contributors who have commit access to the OpenSSL source code repository. Committers review and commit their own patches as well as those of other contributors.

How to become a committer?

Commit access is granted by the OpenSSL Management Committee (OMC) (see the OpenSSL bylaws).

We welcome contributors who become domain experts in some part of the library (for example, low-level crypto) as well as generalists who contribute to all areas of the codebase. All committers share the responsibility for the overall health of the project: aside from contributing quality features, committers are team players who fix bugs, address open issues, review community contributions, and improve tests and documentation. Committers are also shepherds of the OpenSSL community and its code of conduct.

To become a committer, start by contributing code. Read our coding style, and get to know our build and test system. Then, use the project roadmap, Github issue tracker, and our mailing lists find impactful ideas to work on. Seek feedback from multiple OMC members to understand the project, and to support your application. Let them know that you'd like to become a committer - they'll nominate you when your code review record demonstrates impact as well as understanding of the codebase and coding style (usually after a few months of activity). The final decision to grant commit access is taken by an OMC vote.

How to maintain commit status?

To maintain commit status, you should stay active in the project. As stated in the project bylaws, if you remain inactive for several months, your commit access will be withdrawn - but you are always welcome back, just ask an OMC member to re-nominate you.

In the unlikely and unfortunate event that your actions conflict with the project objectives or are otherwise disruptive, commit access may also be revoked by vote of the OMC.

Code reviews

All submissions must be reviewed and approved by at least two committers, one of whom must also be an OMC member. If the author is also a committer then that counts as one of the reviews. In other words:

  • OMC members need one approval from any committer
  • Committers need one approval from a committer within the OMC
  • Contributors without commit rights need two approvals, including one from the OMC.

This process may seem a little heavy, but OpenSSL is a large, complicated codebase, and we think two reviews help prevent security bugs, as well as disseminate knowledge to the growing contributor base.

Contributors without commit rights cannot formally approve patches but are nevertheless welcome to comment on submissions and do technical reviews. We always value another pair of eyes, and volunteering for reviews counts favourably towards becoming a committer. As an author, we ask that you address all comments, even if you already have the necessary approvals.

If you have trouble finding consensus on a difficult review, reach out to the OMC at openssl-team@openssl.org (private, moderated) or committers at openssl-dev@openssl.org (public). On GitHub, you can reach OMC members at @openssl/team, and committers can be found at @openssl/dev.

Commit workflow

We do code reviews on GitHub. The OpenSSL GitHub repository is a mirror, so we do not merge on GitHub. When you become a committer, we'll send you instructions to get commit access to the main repository. To have handy links to review history, we record the reviewers and GitHub pull request IDs in commit headers. We have some helper scripts in the tools repo to add these headers automatically.

We don't use merge commits.

If at any point during development or review you discover a potential security issue, we ask that you report it to openssl-security@openssl.org and don't discuss it further in public. We review security sensitive patches privately, off GitHub. We do not currently have a way to open access to those reviews after the patches have been released.

A note on CLAs

All authors, including committers, must have current CLAs on file. A CLA is not required for trivial contributions (e.g. the fix of a spelling mistake). If all reviewers as well as the original author agree that the submission is trivial, the commit text should include "CLA: trivial."