Skip to content
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

Jump to bottom

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

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 1 commit
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
39 changes: 39 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,39 @@
# 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
nhorman marked this conversation as resolved.
Show resolved Hide resolved
general use
* Lack of popular use (i.e. balancing code size vs consumption frequency)
nhorman marked this conversation as resolved.
Show resolved Hide resolved

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 to access these algorithms while allowing applications
that don't require them to inadvertently continue to use them.
nhorman marked this conversation as resolved.
Show resolved Hide resolved

## Constraints on moving an algorithm to the legacy provider
1) Migration of an algorithm to the legacy provider must occur on a semantically
nhorman marked this conversation as resolved.
Show resolved Hide resolved
versioned major release boundary. Once a major release includes a given
nhorman marked this conversation as resolved.
Show resolved Hide resolved
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
nhorman marked this conversation as resolved.
Show resolved Hide resolved
semantically versioned patch level release (see announcement mechanism below)
nhorman marked this conversation as resolved.
Show resolved Hide resolved

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.


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

## 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 ALG-DEPRECATIONS.md file in the source code root directory for
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 an interesting idea to list the deprecations. Perhaps we should not confine this just to algorithms but to other things deprecated from now on?

Copy link
Author

Choose a reason for hiding this comment

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

I'm fine with expanding a deprecation list, sure. Maybe rename the file to DEPRECATIONS.md, and have a section for legacy migrations, as well as sections for any other distinct deprecation in the future?

Copy link
Member

Choose a reason for hiding this comment

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

Yes, that's what I meant.

OpenSSL. This file will list the algorithm SN, NID, the date at which the
deprecation was announced, and the date at which the algorithm was removed from
the source provider
nhorman marked this conversation as resolved.
Show resolved Hide resolved

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.