Richard Levitte levitte at
Sat Feb 22 09:43:30 UTC 2020

On Sat, 22 Feb 2020 00:03:05 +0100,
Matt Caswell wrote:
> On 21/02/2020 20:33, Matthew Lindner wrote:
> > I think any deprecated apps or options that must be kept and not
> > implemented in the new interface should print a warning when used in
> > that case then, and only do that when it's impossible to implement it
> > in the current release.
> I agree with this. We already do that if you use a deprecated
> application. I'm not so sure we've been quite so careful with the
> deprecated options, so we should check that.

We haven't been very careful at all, all we've done so far is to say
that they are deprecated, nothing else said.  So yeah, I completely
agree.  We also need to decide what such an update should look like.

Looking through some manuals on my Linux installation, I find
deprecation notices in:

- the DESCRIPTION section, which seems to happen when all the
  functions described on the page are deprecated.
  Ref: freehostent(3), gets(3)
- the NOTES sections, which seems to be typically done when only some
  of the functions described on the page are deprecated.
  Ref: dlopen(3),
- as part of the function description
  Ref: getwd(3)
- the CONFORMING TO section, when an external standardisation
  (typically POSIX, LSB, ...) has deprecated a function.
  Ref: bzero(3), gets(3)
- a dedicated deprecation section like DEPRECATED INTERFACES
  Ref: ldap(3) (all applicable LDAP manpages, actually, such as

For those that don't have direct access to a Linux box:

My personal preference is either the whole page deprecation for pages
where all described functions are deprecated (so, early in DESCRIPTION,
like freehostent(3)), or a dedicated section like the LDAP manpages.

> > 
> > That's not at all clear with the speed app for example. (That speed
> > app was deprecated I just found out in this email thread.)
> > 
> That's not actually what I said. The speed app itself is not deprecated.
> There are options to the speed app, which are deprecated. Its quite
> possible we don't print a warning for those - which we should do.

I wholeheartedly think that we should replace the asymmetric tests
with the EVP variants, to be used with the '-evp' option.  Just
dropping them isn't a great solution.
(as a matter of fact, I would turn everything to go through the EVP
interface, whether the '-evp' option has been given or not)

Richard ( std::mantra: PR welcome! )

Richard Levitte         levitte at
OpenSSL Project

More information about the openssl-project mailing list