Skip to content

Add a policy for migration of algorithms to the legacy provider #67

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

Add a policy for migration of algorithms to the legacy provider #67

Changes from 3 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
4592ed3
Add a policy for migration of algorithms to the legacy provider
nhorman Apr 23, 2024
d24a167
fixup! Add a policy for migration of algorithms to the legacy provider
nhorman Apr 23, 2024
3e03520
fixup! Add a policy for migration of algorithms to the legacy provider
nhorman Apr 23, 2024
162d337
Update policies/legacy-migration.md
nhorman Oct 3, 2024
7805f50
Update policies/legacy-migration.md
nhorman Oct 3, 2024
ca136c9
Fixing up syntax nits
nhorman Oct 3, 2024
249d229
Fixing NID comment
nhorman Oct 3, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions policies/legacy-migration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
# Legacy Provider Policy

## Purpose
The Legacy Provider exists to create an opt-in availability mechanism for
algorithms that, for various reasons, should have their use discouraged. These
reasons include, but are not limited to:

* Discovered security issues leaving the algorithm in question unsafe for
general use

* Lack of popular use (i.e. balancing code size vs consumption frequency)

OpenSSL recognizes that consumption of these algorithms may continue to be
required by consuming applications after the conditions above have been
recognized. The Legacy provider exists to provide a mechanism for such
applications to continue having access to these algorithms while preventing
applications that don't require them from inadvertently using them.

## Constraints on moving an algorithm to the legacy provider

1) Migration of an algorithm to the legacy provider must occur on a semantically
versioned major release boundary. Once a major release includes a given
algorithm in a given provider, it must remain there for every minor release in
that major stream.

2) Prior to migration, the migration must be announced for at least 1
semantically versioned minor release (see announcement mechanism below).

3) Coincidental to the announcement above, the algorithm in question may be made
available in both the source provider and the legacy provider.
Copy link
Contributor

@paulidale paulidale Jul 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

source provider? Did you mean default provider?

Copy link
Author

@nhorman nhorman Jul 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used the term source, as I didn't want to constrain deprecation to only the default provider. i.e. if we ever want to deprecate algorithms in the fips provider, or if we create say a pq provider in the future, this same process might be useable.

Copy link
Member

@levitte levitte Oct 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only place this file says "source provider". Everywhere else, this file says "default provider"... would that make you reconsider?

Copy link
Author

@nhorman nhorman Oct 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does make me reconsider, but I think its an open question of wording. do we want to constrain this policy to the default provider only, or should it apply to any non-legacy provider (default/base/fips/etc)?

Copy link
Member

@levitte levitte Oct 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last time I checked, default has all the implementations that are in base and fips combined. base is just there to be combined with fips to give it support stuff that can't be in the latter.

Copy link
Member

@levitte levitte Nov 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking back at this, I would go for consistency. Either "default provider", or "source provider", everywhere.


## Promotion of algorithms in the legacy provider to the default provider
Should the need arise, legacy provider algorithms may be promoted to the default
provider at any time. Removal from the Legacy provider should occur only on
semantically versioned major release boundaries.

## Migration announcement mechanism
Announcements of migrations from the default provider to the Legacy provider is
made via the DEPRECATIONS.md file in the source code root directory for
OpenSSL. This file will list the algorithm SN, NID, the version in which the
deprecation was announced, and the version in which the algorithm is to be
removed from the default provider.