Deprecations

[Matt Caswell]

On 21/02/2020 08:06, Kurt Roeckx wrote:
> In the apps, a lot of the files define
> OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do
> it. We should stop using the deprecated functions ourself. If
> there is no way to do this using non-deprecated functions, the
> function should probably not have been deprecated in the first
> place.
> 
> The apps might have functionality that we want to deprecate too,
> that depends on the deprecated functions. In which case we should
> also mark that as deprecated, and the apps should always build in
> no-deprecation mode.

I think we have a number of strategies for dealing with deprecated APIs
in the apps depending on the situation:

1) Ideally we just rewrite the functionality using non-deprecated APIs

2) In some cases that isn't possible for some reason. For example in the
"passwd" app the "-crypt" option uses the deprecated API "DES_crypt". We
have chosen not to provide an alternative for this API, so in this case
the option itself is deprecated.[1] There are other examples of this in
the "speed" application where a particular option specifically tests the
speed of the low-level APIs (i.e. the "-evp" option hasn't been used).
Again in those cases the options themselves are deprecated.

3) In some cases we have chosen to deprecate an entire application. This
is usually because the whole application is written depending on the
low-level APIs and there is an alternative application available that
does the same thing and uses the high-level APIs. Given the existence of
the other application there seems little point in spending a lot of time
rewriting an entire app when we have equivalent functionality elsewhere.
Examples of this are dhparam, dsaparam and ecparam which are deprecated
in favour of pkeyparam. The user gets a warning displayed when they use
one of these deprecated applications.

Everything should build in a no-deprecated build. In the case of (1) the
functionality is obviously still present because we've rewritten it. In
(2) the deprecated options are no longer available and in (3) the whole
command is no longer available. This seems reasonable to me since the
user has specifically requested a build without deprecated functionality
in it.

In the case of both (2) and (3) where the user has not requested a
no-deprecated build, the use of the deprecated APIs obviously still
remains and therefore we need to use OPENSSL_SUPPRESS_DEPRECATED. This
will eventually disappear in future releases as the deprecated APIs are
removed.

Matt



[1] I note BTW that although the option is deprecated this doesn't seem
to have been reflected in the documentation - nor do I see any code to
indicate to the end user that a deprecated option has been used. We
should probably do that.




> 
> We might also be deprecating APIs that we don't use ourself, so
> it's harder to know if there are alternatives for it.
> 
> It would also be nice that if you deprecate a function, that you
> point to the alternative way to do the same thing in the manual.
> 
> 
> Kurt
>