Re: Deprecations

[Salz, Rich]

>Moreover, the deprecated commands print something to the effect of: "The 
>command dsa is deprecated. Use ‘pkey’ instead." when executed.

I hope it only does that
If (isatty(0) && isatty(1) && isatty(2)) {
BIO_printf(bio_errerr, “%s: This command is 
deprecated, use the \”%s\” command instead.\n”,
prog, “replacement”);

That is, only if “interactive and print to stderr

Re: Deprecations

[Dr Paul Dale]

Matthew,

Good idea.  I’ll add it.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 5 Mar 2020, at 8:55 am, Matthew Lindner  wrote:
> 
> Shouldn't the deprecation notice that's printed also print the version it was 
> deprecated in?
> 
> - Matthew Lindner
> 
>> On Mar 4, 2020, at 2:48 PM, Dr Paul Dale > <mailto:paul.d...@oracle.com>> wrote:
>> 
>> EXTERNAL MAIL: openssl-project-boun...@openssl.org 
>> <mailto:openssl-project-boun...@openssl.org>
>> 
>> Unless I’ve missed something, the documentation should specify the 
>> alternatives.  Mostly these are one to one, but in one case it is one to two 
>> (and there both are listed).
>> With the caveat that I might not have got every place or detail correct.
>> 
>> Moreover, the deprecated commands print something to the effect of: "The 
>> command dsa is deprecated. Use ‘pkey’ instead." when executed.
>> 
>> 
>> Pauli
>> -- 
>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
>> Phone +61 7 3031 7217
>> Oracle Australia
>> 
>> 
>> 
>> 
>>> On 5 Mar 2020, at 5:15 am, Kurt Roeckx >> <mailto:k...@roeckx.be>> wrote:
>>> 
>>> On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:
>>>> 
>>>> 
>>>> On 28/02/2020 23:43, Dr Paul Dale wrote:
>>>>> Any suggestions for a consensus on this thread?
>>>> 
>>>> I think we can probably agree that:
>>>> 
>>>> - Command option deprecations should be handled better
>>>> - We should look at whether we can resurrect some of the "old" commands
>>>> (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)
>>> 
>>> What about at least pointing to the alternative function in the
>>> documentation?
>>> 
>>> 
>>> Kurt
>>> 
>> 
> 

Re: Deprecations

[Matthew Lindner]

Shouldn't the deprecation notice that's printed also print the version it was 
deprecated in?

- Matthew Lindner

On Mar 4, 2020, at 2:48 PM, Dr Paul Dale 
mailto:paul.d...@oracle.com>> wrote:


EXTERNAL MAIL: 
openssl-project-boun...@openssl.org<mailto:openssl-project-boun...@openssl.org>


Unless I’ve missed something, the documentation should specify the 
alternatives.  Mostly these are one to one, but in one case it is one to two 
(and there both are listed).
With the caveat that I might not have got every place or detail correct.

Moreover, the deprecated commands print something to the effect of: "The 
command dsa is deprecated. Use ‘pkey’ instead." when executed.


Pauli
--
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
Phone +61 7 3031 7217
Oracle Australia




On 5 Mar 2020, at 5:15 am, Kurt Roeckx mailto:k...@roeckx.be>> 
wrote:

On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:


On 28/02/2020 23:43, Dr Paul Dale wrote:
Any suggestions for a consensus on this thread?

I think we can probably agree that:

- Command option deprecations should be handled better
- We should look at whether we can resurrect some of the "old" commands
(possibly by writing them as wrappers for genpkey, pkey and pkeyutl)

What about at least pointing to the alternative function in the
documentation?


Kurt

Re: Deprecations

[Dr Paul Dale]

Unless I’ve missed something, the documentation should specify the 
alternatives.  Mostly these are one to one, but in one case it is one to two 
(and there both are listed).
With the caveat that I might not have got every place or detail correct.

Moreover, the deprecated commands print something to the effect of: "The 
command dsa is deprecated. Use ‘pkey’ instead." when executed.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 5 Mar 2020, at 5:15 am, Kurt Roeckx  wrote:
> 
> On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:
>> 
>> 
>> On 28/02/2020 23:43, Dr Paul Dale wrote:
>>> Any suggestions for a consensus on this thread?
>> 
>> I think we can probably agree that:
>> 
>> - Command option deprecations should be handled better
>> - We should look at whether we can resurrect some of the "old" commands
>> (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)
> 
> What about at least pointing to the alternative function in the
> documentation?
> 
> 
> Kurt
> 

Re: Deprecations

[Matt Caswell]

On 04/03/2020 19:15, Kurt Roeckx wrote:
> On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:
>>
>>
>> On 28/02/2020 23:43, Dr Paul Dale wrote:
>>> Any suggestions for a consensus on this thread?
>>
>> I think we can probably agree that:
>>
>> - Command option deprecations should be handled better
>> - We should look at whether we can resurrect some of the "old" commands
>> (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)
> 
> What about at least pointing to the alternative function in the
> documentation?

Yes, we should do that. Pauli is currently investigating the possibility
of rewriting the old commands using EVP:

https://github.com/openssl/openssl/pull/11225

Matt

Re: Deprecations

[Kurt Roeckx]

On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote:
> 
> 
> On 28/02/2020 23:43, Dr Paul Dale wrote:
> > Any suggestions for a consensus on this thread?
> 
> I think we can probably agree that:
> 
> - Command option deprecations should be handled better
> - We should look at whether we can resurrect some of the "old" commands
> (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)

What about at least pointing to the alternative function in the
documentation?


Kurt

Re: Deprecations

[Dr Paul Dale]

I've started working on moving some of the old commands forward using PKEY 
calls.  My intention is for them to still print out a deprecated message when 
run but for them to not actually be removed by the no-deprecated configure 
option.

Having them print equivalent pkey command looks to be somewhat problematic.  
There isn’t a 1:1 conversion and some of the legacy options simply aren’t 
supported.


I’m hoping to have a preliminary PR up later this week.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 2 Mar 2020, at 9:41 pm, Matt Caswell  wrote:
> 
> 
> 
> On 28/02/2020 23:43, Dr Paul Dale wrote:
>> Any suggestions for a consensus on this thread?
> 
> I think we can probably agree that:
> 
> - Command option deprecations should be handled better
> - We should look at whether we can resurrect some of the "old" commands
> (possibly by writing them as wrappers for genpkey, pkey and pkeyutl)
> 
> I am slightly concerned that the latter option (rewriting as wrappers)
> may turn into a big black hole of effort. It *might* be easier to just
> rewrite them as-is to use EVP. Whichever approach we take, I don't think
> this should be a goal for alpha1.
> 
> Matt
> 
>> 
>> Pauli
>> -- 
>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
>> Phone +61 7 3031 7217
>> Oracle Australia
>> 
>> 
>> 
>> 
>>> On 24 Feb 2020, at 5:08 pm, Dr Paul Dale >> <mailto:paul.d...@oracle.com>> wrote:
>>> 
>>> Most of the conversions to using PKEY were straightforward.  One
>>> didn’t require any changes (dsa but my memory is suspect).  One seemed
>>> quite difficult.  Some I didn’t check.
>>> 
>>> Modifying the commands so that they continue to work and print (to
>>> stderr) an alternative pkey based command might be workable too.
>>> 
>>> 
>>> Pauli
>>> -- 
>>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
>>> Phone +61 7 3031 7217
>>> Oracle Australia
>>> 
>>> 
>>> 
>>> 
>>>> On 24 Feb 2020, at 5:53 am, Viktor Dukhovni
>>>> mailto:openssl-us...@dukhovni.org>> wrote:
>>>> 
>>>>> On Feb 22, 2020, at 4:53 AM, Richard Levitte >>>> <mailto:levi...@openssl.org>> wrote:
>>>>> 
>>>>> Something that could be done is to take all those aged commands and
>>>>> rewrite them as wrappers for genpkey, pkey and pkeyutl.  Simply create
>>>>> and populate a new argv and call genpkey_main(), pkey_main() or
>>>>> pkeyutl_main().
>>>> 
>>>> Agreed, that sounds quite reasonable at first blush, and could be
>>>> fantastic
>>>> if it can be made to work (no immediate obstacles come to mind).
>>>> 
>>>> -- 
>>>> Viktor.
>>>> 
>>> 
>> 

Re: Deprecations

[Matt Caswell]

On 28/02/2020 23:43, Dr Paul Dale wrote:
> Any suggestions for a consensus on this thread?

I think we can probably agree that:

- Command option deprecations should be handled better
- We should look at whether we can resurrect some of the "old" commands
(possibly by writing them as wrappers for genpkey, pkey and pkeyutl)

I am slightly concerned that the latter option (rewriting as wrappers)
may turn into a big black hole of effort. It *might* be easier to just
rewrite them as-is to use EVP. Whichever approach we take, I don't think
this should be a goal for alpha1.

Matt

> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 
>> On 24 Feb 2020, at 5:08 pm, Dr Paul Dale > <mailto:paul.d...@oracle.com>> wrote:
>>
>> Most of the conversions to using PKEY were straightforward.  One
>> didn’t require any changes (dsa but my memory is suspect).  One seemed
>> quite difficult.  Some I didn’t check.
>>
>> Modifying the commands so that they continue to work and print (to
>> stderr) an alternative pkey based command might be workable too.
>>
>>
>> Pauli
>> -- 
>> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
>> Phone +61 7 3031 7217
>> Oracle Australia
>>
>>
>>
>>
>>> On 24 Feb 2020, at 5:53 am, Viktor Dukhovni
>>> mailto:openssl-us...@dukhovni.org>> wrote:
>>>
>>>> On Feb 22, 2020, at 4:53 AM, Richard Levitte >>> <mailto:levi...@openssl.org>> wrote:
>>>>
>>>> Something that could be done is to take all those aged commands and
>>>> rewrite them as wrappers for genpkey, pkey and pkeyutl.  Simply create
>>>> and populate a new argv and call genpkey_main(), pkey_main() or
>>>> pkeyutl_main().
>>>
>>> Agreed, that sounds quite reasonable at first blush, and could be
>>> fantastic
>>> if it can be made to work (no immediate obstacles come to mind).
>>>
>>> -- 
>>> Viktor.
>>>
>>
> 

Re: Deprecations

[Dr Paul Dale]

Any suggestions for a consensus on this thread?

Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 24 Feb 2020, at 5:08 pm, Dr Paul Dale  wrote:
> 
> Most of the conversions to using PKEY were straightforward.  One didn’t 
> require any changes (dsa but my memory is suspect).  One seemed quite 
> difficult.  Some I didn’t check.
> 
> Modifying the commands so that they continue to work and print (to stderr) an 
> alternative pkey based command might be workable too.
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 
>> On 24 Feb 2020, at 5:53 am, Viktor Dukhovni > > wrote:
>> 
>>> On Feb 22, 2020, at 4:53 AM, Richard Levitte >> > wrote:
>>> 
>>> Something that could be done is to take all those aged commands and
>>> rewrite them as wrappers for genpkey, pkey and pkeyutl.  Simply create
>>> and populate a new argv and call genpkey_main(), pkey_main() or
>>> pkeyutl_main().
>> 
>> Agreed, that sounds quite reasonable at first blush, and could be fantastic
>> if it can be made to work (no immediate obstacles come to mind).
>> 
>> -- 
>>  Viktor.
>> 
> 

Re: Deprecations

[Dr Paul Dale]

Most of the conversions to using PKEY were straightforward.  One didn’t require 
any changes (dsa but my memory is suspect).  One seemed quite difficult.  Some 
I didn’t check.

Modifying the commands so that they continue to work and print (to stderr) an 
alternative pkey based command might be workable too.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 24 Feb 2020, at 5:53 am, Viktor Dukhovni  
> wrote:
> 
>> On Feb 22, 2020, at 4:53 AM, Richard Levitte  wrote:
>> 
>> Something that could be done is to take all those aged commands and
>> rewrite them as wrappers for genpkey, pkey and pkeyutl.  Simply create
>> and populate a new argv and call genpkey_main(), pkey_main() or
>> pkeyutl_main().
> 
> Agreed, that sounds quite reasonable at first blush, and could be fantastic
> if it can be made to work (no immediate obstacles come to mind).
> 
> -- 
>   Viktor.
> 

Re: Deprecations

[Viktor Dukhovni]

> On Feb 22, 2020, at 4:53 AM, Richard Levitte  wrote:
> 
> Something that could be done is to take all those aged commands and
> rewrite them as wrappers for genpkey, pkey and pkeyutl.  Simply create
> and populate a new argv and call genpkey_main(), pkey_main() or
> pkeyutl_main().

Agreed, that sounds quite reasonable at first blush, and could be fantastic
if it can be made to work (no immediate obstacles come to mind).

-- 
Viktor.

Re: Deprecations

[Richard Levitte]

On Sat, 22 Feb 2020 00:51:17 +0100,
Kurt Roeckx wrote:
> Some equivalants:
> openssl dhparam 2048
> openssl genpkey -genparam --algorithm DH -pkeyopt dh_paramgen_prime_len:2048
> 
> openssl dsaparam 2048
> openssl genpkey -genparam -algorithm DSA -pkeyopt dsa_paramgen_bits:2048

Side note: I never quite understood why we had to have such verbose
pkey opts.  "prime_len" and "bits" would have been enough, the rest is
known by context (the command line already specifies that it wants to
generate domain parameters and that the algorithm is DH, or DSA)

I have to agree with Viktor that some of those pkey commands are
overly complicated at times...  it's a bit hard to undo at this point,
though, apart from creating an entirely new openssl command with a
different, and possibly more intuitive interface.

Something that could be done is to take all those aged commands and
rewrite them as wrappers for genpkey, pkey and pkeyutl.  Simply create
and populate a new argv and call genpkey_main(), pkey_main() or
pkeyutl_main().

std::mantra: PR welcome!

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Deprecations

[Richard Levitte]

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
  ldap_abandon(3))

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

http://man7.org/linux/man-pages/man3/freehostent.3.html
http://man7.org/linux/man-pages/man3/gets.3.html
http://man7.org/linux/man-pages/man3/dlopen.3.html
http://man7.org/linux/man-pages/man3/getwd.3.html
http://man7.org/linux/man-pages/man3/bzero.3.html
http://man7.org/linux/man-pages/man3/ldap.3.html
http://man7.org/linux/man-pages/man3/ldap_abandon.3.html

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)

Cheers,
Richard ( std::mantra: PR welcome! )

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Deprecations

[Dr Paul Dale]

The added complexity was of some concern to me when doing the deprecations.

I suspect we’ll also encounter difficulties getting 100% equivalent behaviour 
via PKEY.  There are some pretty arcane options in some of these.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 22 Feb 2020, at 9:51 am, Kurt Roeckx  wrote:
> 
> On Fri, Feb 21, 2020 at 11:27:55PM +, Matt Caswell wrote:
>> 
>> 
>> On 21/02/2020 23:18, Kurt Roeckx wrote:
>>> On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:
>>>> 
>>>> 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]
>>> 
>>> For some reason I seem to have missed various things.
>>> 
>>> But I think deprecating tools like dhparam, dsaparam in favour of
>>> genpkey is something that we should reconsider.
>> 
>> What is your reasoning?
>> 
>> (I just realised that what the CHANGES entry says is that
>> dhparam/dsaparam are deprecated in favour of pkeyparam - but actually I
>> think the equivalent functionality is more split between genpkey and
>> pkeyparam)
> 
> Some equivalants:
> openssl dhparam 2048
> openssl genpkey -genparam --algorithm DH -pkeyopt dh_paramgen_prime_len:2048
> 
> openssl dsaparam 2048
> openssl genpkey -genparam -algorithm DSA -pkeyopt dsa_paramgen_bits:2048
> 
> 
> If you search internet, you will more than likely find the first
> ones. They are very easy. I have to look up at the manual page
> examples to know how to use genpkey.
> 
> 
> Kurt

Re: Deprecations

[SHANE LONTIS]

> On 22 Feb 2020, at 1:36 pm, Viktor Dukhovni  
> wrote:
> 
> But there's nothing like
> using a screwdriver to turn a screw, rather than banging it in with
> an all-purpose hammer!

If we are trying to tell users to not use the low level API’s, and then we go 
and use them everywhere in apps it is not really sending the correct message.
If we need to keep them - then they probably would need to be rewritten in 
terms of evp. (Or parse the parameters and pass them to another app call) :)). 
Either way its quite a bit of work.


> If you search internet, you will more than likely find the first
> ones. They are very easy. I have to look up at the manual page
> examples to know how to use genpkey.

Agreed. Being able to list all the pkey options from the app might be helpful 
here?

Re: Deprecations

[Viktor Dukhovni]

On Sat, Feb 22, 2020 at 12:51:17AM +0100, Kurt Roeckx wrote:

> > (I just realised that what the CHANGES entry says is that
> > dhparam/dsaparam are deprecated in favour of pkeyparam - but actually I
> > think the equivalent functionality is more split between genpkey and
> > pkeyparam)
> 
> Some equivalants:
> openssl dhparam 2048
> openssl genpkey -genparam --algorithm DH -pkeyopt dh_paramgen_prime_len:2048
> 
> openssl dsaparam 2048
> openssl genpkey -genparam -algorithm DSA -pkeyopt dsa_paramgen_bits:2048

+100.  The new commands are nice for professionally written utilities
that need to be algorithm polymorphic, ...  But there's nothing like
using a screwdriver to turn a screw, rather than banging it in with
an all-purpose hammer!

> If you search internet, you will more than likely find the first
> ones. They are very easy. I have to look up at the manual page
> examples to know how to use genpkey.

Yes, same here.

-- 
Viktor.

Re: Deprecations

[Viktor Dukhovni]

On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:

> 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]

Dropping "dhparam" is rather an incompatible change.  It is widely used,
and its replacemnt is much more complex, and does not appear in how-to
guides that explain how to generate DH parameters.  Whatever API is
used in "pkeyparam", needs to be inserted into dhparam without changing
its CLI.

The same applies to genrsa, ... and even though I'm sometimes masochist
enough to use "genpkey" (after checking the manpage again, or re-reading
my own mkcert.sh script), it somehow has never managed to get to a point
where I can emit its various options from finger memory.

-- 
Viktor.

Re: Deprecations

[Kurt Roeckx]

On Fri, Feb 21, 2020 at 11:27:55PM +, Matt Caswell wrote:
> 
> 
> On 21/02/2020 23:18, Kurt Roeckx wrote:
> > On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:
> >>
> >> 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]
> > 
> > For some reason I seem to have missed various things.
> > 
> > But I think deprecating tools like dhparam, dsaparam in favour of
> > genpkey is something that we should reconsider.
> 
> What is your reasoning?
> 
> (I just realised that what the CHANGES entry says is that
> dhparam/dsaparam are deprecated in favour of pkeyparam - but actually I
> think the equivalent functionality is more split between genpkey and
> pkeyparam)

Some equivalants:
openssl dhparam 2048
openssl genpkey -genparam --algorithm DH -pkeyopt dh_paramgen_prime_len:2048

openssl dsaparam 2048
openssl genpkey -genparam -algorithm DSA -pkeyopt dsa_paramgen_bits:2048


If you search internet, you will more than likely find the first
ones. They are very easy. I have to look up at the manual page
examples to know how to use genpkey.


Kurt

Re: Deprecations

[Matthew Lindner]

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.

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.)

- Matthew Lindner

> On Feb 21, 2020, at 12:14 PM, Matt Caswell  wrote:
> 
> EXTERNAL MAIL: openssl-project-boun...@openssl.org
> 
> 
> On 21/02/2020 19:45, Matthew Lindner wrote:
>> As a user I'm strongly in favor of this. It gives an example of how
>> to implement something using the new interfaces. Even in 1.1.1 there
>> are things that are impossible to implement without using low level
>> interfaces. The applications should be guides on how to correctly
>> implement something and will point out interface deficiencies. 3.0.0
>> should not ship with deprecated code in the apps (and 1.1.1 should
>> stop using deprecated code in its apps).
> 
> As I mentioned in my earlier post I don't believe that this is feasible:
> 
> - In some cases an API has been deliberately deprecated with no
> replacement. This functionality is also deprecated and will eventually
> be removed from the app at the same time that the deprecated API is removed.
> 
> - In the case of the speed app, the whole point of some functionality is
> to test the speed of the deprecated API. When the deprecated APIs go, so
> will that functionality from speed.
> 
> - In other cases whole apps are deprecated in favour of a different one
> that does the same job. The deprecated app will be kept around until the
> deprecated APIs they use are removed, and then the app will also be
> removed. Application authors looking for an example should refer to the
> non-deprecated alternative app.
> 
> For all of the above reasons there will have to be some deprecated APIs
> still being used in the apps in 3.0. Any uses that remain are expected
> to be removed at the same time as the APIs themselves are removed.
> 
> Matt
> 
> 
>> 
>> - Matthew Lindner
>> 
>>> On Feb 21, 2020, at 12:06 AM, Kurt Roeckx  wrote:
>>> 
>>> EXTERNAL MAIL: openssl-project-boun...@openssl.org
>>> 
>>> Hi,
>>> 
>>> We seem to be deprecating a lot of the old APIs, which I think is a
>>> good thing. But I think we might either be deprecating too much, or
>>> not actually using the alternatives ourself.
>>> 
>>> 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.
>>> 
>>> 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
>>> 
>>> 
>> 

Re: Deprecations

[Matt Caswell]

On 21/02/2020 23:18, Kurt Roeckx wrote:
> On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:
>>
>> 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]
> 
> For some reason I seem to have missed various things.
> 
> But I think deprecating tools like dhparam, dsaparam in favour of
> genpkey is something that we should reconsider.

What is your reasoning?

(I just realised that what the CHANGES entry says is that
dhparam/dsaparam are deprecated in favour of pkeyparam - but actually I
think the equivalent functionality is more split between genpkey and
pkeyparam)

Matt

Re: Deprecations

[Kurt Roeckx]

On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote:
> 
> 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]

For some reason I seem to have missed various things.

But I think deprecating tools like dhparam, dsaparam in favour of
genpkey is something that we should reconsider.


Kurt

Re: Deprecations

[Matt Caswell]

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.

> 
> 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.

Matt



> - Matthew Lindner
> 
>> On Feb 21, 2020, at 12:14 PM, Matt Caswell 
>> wrote:
>> 
>> EXTERNAL MAIL: openssl-project-boun...@openssl.org
>> 
>> 
>> On 21/02/2020 19:45, Matthew Lindner wrote:
>>> As a user I'm strongly in favor of this. It gives an example of
>>> how to implement something using the new interfaces. Even in
>>> 1.1.1 there are things that are impossible to implement without
>>> using low level interfaces. The applications should be guides on
>>> how to correctly implement something and will point out interface
>>> deficiencies. 3.0.0 should not ship with deprecated code in the
>>> apps (and 1.1.1 should stop using deprecated code in its apps).
>> 
>> As I mentioned in my earlier post I don't believe that this is
>> feasible:
>> 
>> - In some cases an API has been deliberately deprecated with no 
>> replacement. This functionality is also deprecated and will
>> eventually be removed from the app at the same time that the
>> deprecated API is removed.
>> 
>> - In the case of the speed app, the whole point of some
>> functionality is to test the speed of the deprecated API. When the
>> deprecated APIs go, so will that functionality from speed.
>> 
>> - In other cases whole apps are deprecated in favour of a different
>> one that does the same job. The deprecated app will be kept around
>> until the deprecated APIs they use are removed, and then the app
>> will also be removed. Application authors looking for an example
>> should refer to the non-deprecated alternative app.
>> 
>> For all of the above reasons there will have to be some deprecated
>> APIs still being used in the apps in 3.0. Any uses that remain are
>> expected to be removed at the same time as the APIs themselves are
>> removed.
>> 
>> Matt
>> 
>> 
>>> 
>>> - Matthew Lindner
>>> 
 On Feb 21, 2020, at 12:06 AM, Kurt Roeckx 
 wrote:
 
 EXTERNAL MAIL: openssl-project-boun...@openssl.org
 
 Hi,
 
 We seem to be deprecating a lot of the old APIs, which I think
 is a good thing. But I think we might either be deprecating too
 much, or not actually using the alternatives ourself.
 
 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.
 
 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
 
 
>>> 
> 

Re: Deprecations

[Matt Caswell]

On 21/02/2020 22:17, Kurt Roeckx wrote:
> On Fri, Feb 21, 2020 at 09:50:10AM +, 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 

Deprecated since OpenSSL 3.0, can be hidden entirely by defining
B with a suitable version value, see
L:

 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);

=head1 DESCRIPTION

All of the functions described on this page are deprecated.
Applications should instead use L,
L, L and
L.



Matt

> 
> 
> Kurt
> 

Re: Deprecations

[Kurt Roeckx]

On Fri, Feb 21, 2020 at 09:50:10AM +, 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.

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.

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.


Kurt

Re: Deprecations

[Matt Caswell]

On 21/02/2020 19:45, Matthew Lindner wrote:
> As a user I'm strongly in favor of this. It gives an example of how
> to implement something using the new interfaces. Even in 1.1.1 there
> are things that are impossible to implement without using low level
> interfaces. The applications should be guides on how to correctly
> implement something and will point out interface deficiencies. 3.0.0
> should not ship with deprecated code in the apps (and 1.1.1 should
> stop using deprecated code in its apps).

As I mentioned in my earlier post I don't believe that this is feasible:

- In some cases an API has been deliberately deprecated with no
replacement. This functionality is also deprecated and will eventually
be removed from the app at the same time that the deprecated API is removed.

- In the case of the speed app, the whole point of some functionality is
to test the speed of the deprecated API. When the deprecated APIs go, so
will that functionality from speed.

- In other cases whole apps are deprecated in favour of a different one
that does the same job. The deprecated app will be kept around until the
deprecated APIs they use are removed, and then the app will also be
removed. Application authors looking for an example should refer to the
non-deprecated alternative app.

For all of the above reasons there will have to be some deprecated APIs
still being used in the apps in 3.0. Any uses that remain are expected
to be removed at the same time as the APIs themselves are removed.

Matt


> 
> - Matthew Lindner
> 
>> On Feb 21, 2020, at 12:06 AM, Kurt Roeckx  wrote:
>> 
>> EXTERNAL MAIL: openssl-project-boun...@openssl.org
>> 
>> Hi,
>> 
>> We seem to be deprecating a lot of the old APIs, which I think is a
>> good thing. But I think we might either be deprecating too much, or
>> not actually using the alternatives ourself.
>> 
>> 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.
>> 
>> 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
>> 
>> 
> 

Re: Deprecations

[Matthew Lindner]

As a user I'm strongly in favor of this. It gives an example of how to 
implement something using the new interfaces. Even in 1.1.1 there are things 
that are impossible to implement without using low level interfaces. The 
applications should be guides on how to correctly implement something and will 
point out interface deficiencies. 3.0.0 should not ship with deprecated code in 
the apps (and 1.1.1 should stop using deprecated code in its apps).

- Matthew Lindner

> On Feb 21, 2020, at 12:06 AM, Kurt Roeckx  wrote:
> 
> EXTERNAL MAIL: openssl-project-boun...@openssl.org
> 
> Hi,
> 
> We seem to be deprecating a lot of the old APIs, which I think is
> a good thing. But I think we might either be deprecating too much,
> or not actually using the alternatives ourself.
> 
> 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.
> 
> 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
> 
> 

Re: Deprecations

[Salz, Rich]

>A small note about the 'no-deprecated' configuration option: this is an 
> option to simulate the far future when the deprecated stuff has been removed 
> from the public eye. Deprecated openssl commands should not build with such a 
> configuration. 
  
How can that work?  If the deprecated command calls deprecated API's then 
you'll get build failures.
 

Re: Deprecations

[Richard Levitte]

"Salz, Rich"  skrev: (21 februari 2020 17:17:54 CET)
>>A small note about the 'no-deprecated' configuration option: this
>is an option to simulate the far future when the deprecated stuff has
>been removed from the public eye. Deprecated openssl commands should
>not build with such a configuration. 
>  
>How can that work?  If the deprecated command calls deprecated API's
>then you'll get build failures.

It works by not building the deprecated command in that configuration.

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.

Re: Deprecations

[Richard Levitte]

A small note about the 'no-deprecated' configuration option: this is an option 
to simulate the far future when the deprecated stuff has been removed from the 
public eye. Deprecated openssl commands should not build with such a 
configuration. 

Cheers 
Richard 



Kurt Roeckx  skrev: (21 februari 2020 09:06:39 CET)
>Hi,
>
>We seem to be deprecating a lot of the old APIs, which I think is
>a good thing. But I think we might either be deprecating too much,
>or not actually using the alternatives ourself.
>
>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.
>
>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

-- 
Richard by mobile

Re: 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
> 

Deprecations

[Kurt Roeckx]

Hi,

We seem to be deprecating a lot of the old APIs, which I think is
a good thing. But I think we might either be deprecating too much,
or not actually using the alternatives ourself.

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.

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