Add a policy for migration of algorithms to the legacy provider #67
Conversation
nhorman
requested review from
levitte,
arapov,
hlandau,
t8m,
t-j-h and
mattcaswell
| semantically versioned major release boundaries. | ||
|
|
||
| ## Migration announcement mechanism | ||
| Announcements of migrations from a source provider to the Legacy provider is |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
policies/legacy-migration.md
Outdated
|
|
||
| ## Migration announcement mechanism | ||
| Announcements of migrations from a source provider to the Legacy provider is | ||
| made via the ALG-DEPRECATIONS.md file in the source code root directory for |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
| 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 | ||
|
|
|
ping @openssl/committers still looking for input/reviews here |
| 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. |
There was a problem hiding this comment.
source provider? Did you mean default provider?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
This is the only place this file says "source provider". Everywhere else, this file says "default provider"... would that make you reconsider?
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
How is the announcement of a deprecation made, and how is feedback received?
History:
At one stage the RIPE digest was moved to the legacy provider. It was then added back into the default provider after it was found that BITCOIN programmers were not happy that it had been moved.
|
@slontis I was working under the assumption that DEPRECATIONS.md would be the canonical source for an announcement, and that it would be the responsibility of interested parties to review that file regularly and raise issues if/when a given deprecation wasn't appropriate. Given that we follow the 'at least one release prior' process to do the announcement before the actual removal, this (at least to me) provides sufficient warning to make community voices heard. We could additionally announce deprecations elsewhere as well, but I think the problem you may be alluding to is not really a "where we do the announcement" problem but rather a "users don't pay attention until its too late" problem. Honestly I'm not really sure how to solve that one, as no matter how many channels we announce it from, the form that problem takes is invariably that the user didn't look in the right place. My personal opinion is that we shouldn't announce it in a different place, but rather only do so in one single place, and start educating users on what they should do for every release. That is to say, for every release (even if they don't plan to upgrade), users should:
Maybe a wiki page about this would be beneficial |
|
Whether its by mailing list or blog, that is a bit more direct than just polling a file. I think it may be too late by the time someone notices it in a committed file. |
|
That's a fair position, but I'm not sure I agree with it, or perhaps it might be more accurate to say I'm not sure it really makes anything better. The situation as I see it is that, for a given release, end users need to recognize that, even if there is no plan on their part to make use.of the release, that there is action for them to take. Specifically they need to review the release, and identify deprecated apis that they may need to be prepared to stop using (among any number of other things). We can push that information to them in a multitude of ways, but if they don't take the.above requirement to heart, it's going to result in varying degrees of "I didn't know this was happening" complaints. I wonder if there may be a way to have users subscribe to API surfaces to get notified.if changes pertainin to them. |
|
still looking for feedback/consensus here |
|
Usually, we announce deprecations in the release notes. Isn't that an appropriate place? |
Co-authored-by: Richard Levitte <levitte@openssl.org>
Co-authored-by: Richard Levitte <levitte@openssl.org>
| 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 | ||
|
|
| semantically versioned major release boundaries. | ||
|
|
||
| ## Migration announcement mechanism | ||
| Announcements of migrations from a source provider to the Legacy provider is |
There was a problem hiding this comment.
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).
|
no its not removed, because I don't think we've reached consensus on what to do here. Regarding understanding/confusion by reading parties, my understanding is that the audience for this is twofold:
I understand what you mean by (1), saying "source provider" might drive the question "whats the source provider?", but I think that audience will be most focused on where to find announcements, rather than the minutae of where its comming from. Item (2) is really what I'm focused on here. I'm trying to avoid the situation where, in 2 years we have some other provider (not named default) that needs to have a deprecation and the OTC/whatever committee rabbit holes trying to decide if this policy is applicable to providers other than the one named default. We just had a similar discussion when I attempted to limit otc review requirements on repos other than openssl, and there was some very real uncertainty about what repositories that policy applied to. |
No description provided.