Feature Branch Approval Policy

The Time-based Release Policy defines a regular twice-a-year schedule for new OpenSSL versions. In the case of large features that cannot reasonably be implemented and reviewed within a single PR there is a risk that only an incomplete or incorrect implementation of the feature will be merged to the master branch by the time a feature freeze occurs for the next release. To avoid this problem feature branches can be used.

Time-based Release Policy

This policy outlines the systematic process followed for the time-based release of the OpenSSL software library. The approach aims to deliver regular, predictable updates and innovations to users while maintaining optimal workflow and efficient resource management within the OpenSSL organisation. This document covers the release schedule and the various phases that comprise our release cycle: planning, release definition, development, and release stages including alpha, beta, and final release. It also outlines the support lifecycle following each release.

Sponsorship Policy

Purpose The purpose of the Sponsorship Policy (The Policy) is to outline the principles and behaviours adopted by OpenSSL when receiving or providing sponsorship. The Policy will ensure that only appropriate sponsorship is received or provided by OpenSSL, i.e. that sponsorship aligns with OpenSSL’s Mission and Values, community expectations and meets legal requirements. Scope The policy applies to all organisations, individuals and entities that provide sponsorship to OpenSSL and to any organisation, individual or entity that OpenSSL sponsors.

Trademark Policy

Last modified 2022-11-22 Purpose OpenSSL is committed to promoting the use of its open source software. While open source software is generally free to download and modify, the use of open source software does not include the right to OpenSSL Trademarks. The Trademark Policy (The Policy) aims to protect and ensure consistent usage of the OpenSSL trademarks and to clarify how the OpenSSL trademarks may be used. As a part of this process, the OpenSSL trademark is a registered United States trademark of the OpenSSL Software Foundation.

Platform Policy

Platforms are classified as “primary”, “secondary”, “community” and “unadopted”. Support for a new platform should only be added if it is being adopted as a primary, secondary or community platform. Current platforms Primary Definition: A platform that is regularly tested through project CI on a project owned and managed system. New Pull Requests (PRs) should not be merged unless the primary platforms are showing as “green” in CI. If the CI breaks for a branch (such as for a stable version or master) then it should be fixed as a priority.

Information Release Policy

Purpose The purpose of the Information Release Policy (The Policy) is to outline the principles adopted by OpenSSL in the release of information. OpenSSL is committed to transparency and open access to information and will publish as much information as possible while having due regard to our obligation to respect and maintain confidential, commercially valuable and personal information. This policy establishes that a decision to release information is at OpenSSL’s discretion.

Security Policy

Reporting security issues If you wish to report a possible security issue in OpenSSL please notify us. Issue triage We engage resources within OpenSSL to start the investigation and prioritization. We may work privately with individuals who are not core OpenSSL developers, as well as with other organizations and our employers, where we believe this can help with issue investigation, resolution, or testing. Threat Model Certain threats are currently considered outside of the scope of the OpenSSL threat model.

The Public Voting Procedure of OMC

The following regulations complement the OMC Voting Procedures stated in the project bylaws. This policy affects only public votes. Vote Proposal The votes are proposed in pull requests and issues of the general-policies repository on GitHub OpenSSL project. The vote regarding a policy change proposal is recorded directly in the pull request of the policy change proposal. Any other votes are recorded as separate issues in the repository. All votes governed by this procedure must be announced through an e-mail to the OpenSSL Project mailing list.

Policy on Proposing General Policy Changes

This policy represents the way that any additions or changes to the existing policies are proposed, edited, finalized, and approved. The process for minor changes is described in the Minor Edits section. Policy Change Proposal The policy changes or additions are submitted as pull requests in the general-policies repository on GitHub OpenSSL project. Anyone with a GitHub account can submit a policy change proposal pull request. Each policy is placed in an individual file in Markdown format in the policies subdirectory.

Glossary of OpenSSL terms

This is a glossary of terms, it does not include any formal definitions of the included terms. It does, however, link to the formal definition where appropriate. In the event in a conflict between this glossary and the formal definition, the formal definition is always canonical. ABI Application binary interface An ABI compatible release allows a shared library to be replaced with a new version or for applications to be relinked against the new library with the expectation that everything will run.

OpenSSL release versioning policy

This document describes the release versioning scheme used by the OpenSSL project from version 3.0.0 onwards. It also details the level of ABI and API compatibility each version represents. Note: All examples herein are illustrative and do not constitute part of the versioning policy. The version scheme consists a triple of numbers: major.minor.patch. For example, the version 3.0.1 has a major version of 3, a minor version of 0 and a patch version of 1.