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