OpenSSL coding style

This document describes the coding style for the OpenSSL project. It is derived from the Linux kernel coding style. This guide is not distributed as part of OpenSSL itself. Since it is derived from the Linux Kernel Coding Style, it is distributed under the terms of the kernel license. Coding style is all about readability and maintainability using commonly available tools. OpenSSL coding style is simple. Avoid tricky expressions. Chapter 1: Indentation Indentation is four space characters.

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.

Policy for Accepting Assembler Optimisations

New assembler optimisations for any algorithm having a C based implementation in any provider are always acceptable (subject to standard review procedures) for all platforms in the master branch. New assembler optimisations are never acceptable for any platform or provider in a stable release branch. Updates to existing assembler optimisations in a stable release branch are only acceptable where such updates would be allowed under the stable release update policy.

Stable Release Updates Policy

This policy covers allowed changes on release branches. Definitions A stable release is a series beginning with a major or minor release that is not a pre-release, and all its updates. A patch release is an update within a stable release. A public interface is any function, structure or macro declared in a public header file. A bug fix is a fix of functionality of the libraries, modules, applications, or the build system that (all or any items might apply):

Release Requirements Policy

The OpenSSL project team creates the following 5 types of OpenSSL software releases: alpha (pre-)releases beta (pre-)releases major releases minor releases patch releases This policy defines the requirements on the state of a branch in the source tree that must be met before a release from that branch can be done. Alpha Pre-releases As this is just a preview release for testing things that have been worked on in the development branch, the requirements are minimal.

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.

Design Process Policy

Objectives The objective of the design process is to increase the quality of the software engineering process. The production of design documents confers the following benefits: Prior to implementation, the present understanding of the problem domain is documented in a readily accessible fashion. The understanding of other OpenSSL contributors is enhanced, as is their ability to identify any potential issues in the design, or to make related code contributions. After implementation, the design document serves as documentation of the architectural and design decisions and rationale which served as the basis for the implementation of the relevant functionality.

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.

Testing Policy

This applies to all stable and development branches of the main code repository. Within this policy functional behaviour means what the system does, i.e. given a set of inputs it will produce a set of outputs. This does not include how the system does it. For example refactoring or performance improvements do not affect functional behaviour. Except where noted below: All Pull Requests adding new functionality to the applications, libraries, providers or engines must include suitable tests.

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.

Branch Policy

The openssl repository contains the following maintained branches: The default development branch Any type (bug fix, feature, refactoring, …) of pull requests is allowed. The development of the next minor or major release happens there. API/ABI breaking changes are allowed on this branch only if the next release will be a major release. Any changes merged to this branch must be ported to the future major and future minor branches if they are applicable.

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.

The Public Voting Procedure of OTC

The following regulations complement the OTC 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 technical-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 Technical 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 technical-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.

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.

OpenSSL documentation policy

This document describes the code documentation and commenting requirements for the OpenSSL project. The project’s documentation is all about making the libraries and tools more accessible to our users and making the code more maintainable. This policy applies to new submissions, existing code is below par and will be gradually improved. Chapter 1: Command line commands and arguments All new or modified arguments to the commands must be documented in the doc/man1 directory.

Policy on API compatibility in minor releases

The public API of the OpenSSL libraries is defined as functions, macros, data structure declarations, typedefs, and data variables in header files in the include/openssl subdirectory of the source tree and include/openssl subdirectory of the build tree. No changes to existing public API functions and data are permitted. This includes, but is not limited to: constification of arguments; changing void returns to int returns; changing a macro to a function and corrections of spelling.

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.