Matt Caswell matt at
Fri Feb 21 23:00:10 UTC 2020

On 21/02/2020 22:17, Kurt Roeckx wrote:
> On Fri, Feb 21, 2020 at 09:50:10AM +0000, Matt Caswell wrote:
>> 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
> The problem is that many of the apps already define
> OPENSSL_SUPPRESS_DEPRECATED so that you don't know that something
> you're deprecating is used there without checking for it.

This is not the case. The only effect that OPENSSL_SUPPRESS_DEPRECATED
has is that it suppreses deprecated warnings from the compiler. However,
if you don't handle that deprecated code in some way you will get a
build failure in a no-deprecated build because the deprecated function
doesn't exist at all.

*If* we use any deprecated APIs we *must* make an informed decision
about what to do about that API use to avoid a no-deprecated build
failure. Since our no-deprecated builds are working just fine, I don't
believe there are any instances in the apps where we haven't made that
informed decision.

> The commit I was looking at was ada66e78ef535fe80e422bbbadffe8e7863d457c:
> Deprecate the low level Diffie-Hellman functions.
> At least one of the functions being deprecated is DH_check, which
> is still used by dhparam. Dhparam is our replacement for dh and gendh.
> I don't know if any of the other function that were deprecated are
> still used internally or not.

dhparam itself has been deprecated. For that reason we are not
attempting to rewrite it to use non-deprecated APIs. The informed
decision we have made about DH_check use in dhparam is to not build the
whole application in a no-deprecated build:

  *) The command line utilities dhparam, dsa, gendsa and dsaparam have been
     deprecated.  Instead use the pkeyparam, pkey, genpkey and pkeyparam
     programs respectively.
     [Paul Dale]

> The define was added in commit 1ddf2594e18137aeb7ce861e54f46824db76e36f,
> and so when DH_check later got deprecated, nobody noticed that the
> now deprecated function is still being used.
> I think the replacement function is EVP_PKEY_param_check().
> DH_check is not mentioned as deprecated in the manual.

Yes, it is:

 #include <openssl/dh.h>

Deprecated since OpenSSL 3.0, can be hidden entirely by defining
B<OPENSSL_API_COMPAT> with a suitable version value, see

 int DH_generate_parameters_ex(DH *dh, int prime_len, int generator,
BN_GENCB *cb);

 int DH_check(DH *dh, int *codes);
 int DH_check_params(DH *dh, int *codes);

 int DH_check_ex(const DH *dh);
 int DH_check_params_ex(const DH *dh);
 int DH_check_pub_key_ex(const DH *dh, const BIGNUM *pub_key);


All of the functions described on this page are deprecated.
Applications should instead use L<EVP_PKEY_check(3)>,
L<EVP_PKEY_public_check(3)>, L<EVP_PKEY_private_check(3)> and


> Kurt

More information about the openssl-project mailing list