My personal view is that the legacy provider probably isn't worth it as a concept.

While I understand the feeling where, we really don't like DES and want to be able to "get rid of it" (for example), my feeling is the issues it creates aren't really worth the marginal gains of reducing the scope and size of the default provider.

In practice people install both providers. no-legacy can still mask algorithms we have deemed legacy.

OK, so I understand there is a desire to be able to enable and disable legacy algorithms via config because people want to configure apps they didn't make.

Need input on the reasons and rationale behind the legacy provider in the first place. (Chesterton's fence.)

Some suggestions for the policy from OTC discussion:

• We want community involved in the process.
• Proposal for moving algorithms should be announced in advance to gather the community input.
• Moving algorithms should in general be done only on major version change.

Proposed policy

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 to access these algorithms while allowing applications that don't require them to inadvertently continue to use 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 patch level 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.

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 a source provider to the Legacy provider is made via the ALG-DEPRECATIONS file in the source code root directory for 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

OTC: We are OK with the draft policy above. It should be created as a general policy proposal.

proposed here:
openssl/general-policies#67

Proposed policy written. Closing.