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 all 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
46 changes: 46 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,46 @@
# 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 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 one
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

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

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

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

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

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

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
major release boundaries.

## Migration announcement mechanism

Announcements of migrations from a source provider to the Legacy provider is
Copy link
Member

Choose a reason for hiding this comment

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

I would talk about default provider here? FIPS provider has a completely different policy and IMO anything that is in FIPS, should be in default as well.

Copy link
Member

Choose a reason for hiding this comment

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

I believe that talking about source provider will just confuse people. Deprecations and removals from the FIPS provider take different rules (and usually when something is removed or deprecated in FIPS provider, it can stay in the default provider for quite long time after that).

made via the DEPRECATIONS.md file in the source code root directory for
OpenSSL. This file will list all the identities of the algorithm (names,
possible OIDs, possible NIDs), the version in which the deprecation was
announced, and the version in which the algorithm is to be removed from the
source provider. Note that deprecations may also be announced in the release
notes.

Copy link
Member

Choose a reason for hiding this comment

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

Nit: remove spurious line

Copy link
Member

Choose a reason for hiding this comment

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

Still not removed.