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.

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.

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.

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.

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 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.

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.