General Policies on OpenSSL Library

Feature Branch Approval Policy

Mon, 01 Jan 0001 00:00:00 +0000

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. A feature branch is simply a branch in the main git repository that can be used as a target branch for PRs related to a single new feature.

Glossary of OpenSSL terms

Mon, 01 Jan 0001 00:00:00 +0000

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 AI Code and Documentation Contribution Policy

Mon, 01 Jan 0001 00:00:00 +0000

Overview

OpenSSL welcomes contributions from all developers, including those who use AI-assisted coding tools. This policy sets out the rules for using such tools when creating commits for submission to OpenSSL. It applies to anyone that creates such commits (including both project committers and non-committers).

This policy applies to all public OpenSSL repositories, including all repositories under https://github.com/openssl.

These rules exist to protect OpenSSL’s users, its license integrity, and the legal clarity of its codebase.

OpenSSL Library FIPS Module Support Policy

Mon, 01 Jan 0001 00:00:00 +0000

1. Principle

FIPS validated cryptography is delivered by the OpenSSL Library FIPS provider (the “module”), which is validated independently of the OpenSSL Library. A validated module is built from the source of the release it was validated against. It may be used, unchanged, together with a library built from any supported OpenSSL Library release from version 3.0 onwards: provider compatibility is maintained backward and forward across these releases, including future major release series, for as long as the module remains supported under this policy. The support status of an OpenSSL Library release version and the support status of an OpenSSL Library FIPS module are therefore distinct: a module can remain supported after its OpenSSL Library release version has reached end of life.

OpenSSL release versioning policy

Mon, 01 Jan 0001 00:00:00 +0000

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.

Platform Policy

Mon, 01 Jan 0001 00:00:00 +0000

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.

Policy for OpenSSL Committers

Mon, 01 Jan 0001 00:00:00 +0000

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 Foundation or the OpenSSL Corporation directors.

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.

Release Artifacts Signing Policy

Mon, 01 Jan 0001 00:00:00 +0000

This policy covers the cryptographic signing of release artifacts produced by OpenSSL Library release automation, the keys and certificates used to produce those signatures, their lifecycle, and the response to a suspected compromise.

Scope

This policy applies to:

Detached OpenPGP signature files for source distributions published as part of an OpenSSL Library release.
Authenticode signatures on Windows binaries and installers published as part of an OpenSSL Library release.
Any future signing scheme added to the release process by amendment to this policy.

This policy does not apply to signatures produced by individual contributors on their own commits, tags, or correspondence, which are governed by the committer policy and the git workflow.

Security Policy

Mon, 01 Jan 0001 00:00:00 +0000

Reporting security issues

If you wish to report a possible security issue in OpenSSL please notify us by sending an e-mail to openssl-security@openssl.org.

If you have multiple issues to report, please always send a separate e-mail for each issue.

Issue triage

Notifications are received by the OpenSSL Security Response Team (SRT) designated by the OpenSSL Foundation and the OpenSSL Corporation directors. The SRT contains resources from within the OpenSSL Foundation and the OpenSSL Corporation and also members from the Committers community who decided to participate in the SRT.

Time-based Release Policy

Mon, 01 Jan 0001 00:00:00 +0000

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.

Trademark Policy

Mon, 01 Jan 0001 00:00:00 +0000

Last modified 2024-10-08

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 use OpenSSL Trademarks.

The Trademark Policy (The Policy) aims to protect and ensure consistent usage of the OpenSSL Trademarks and to clarify when and how OpenSSL Trademarks may be used.

The Policy aims to: