Hi Matt,
So you are saying configuring with "enable-deprecated" or not won't
make the build different, they are all actually support the deprecated
functions, right ? If yes, then in my application , if I have
"OPENSSL_USE_DEPRECATED"
defined, the depecated functions in my application should still work,
right? But it does not work. And as I imagine, in the openssl header
files(after a successful build), it should have some "#if defines
OPENSSL_USE_DEPRECATED"
like statement, but I don't see it anywhere, can you tell me how it works?
Thanks!
Peter
On Mon, Sep 16, 2019 at 10:52 AM Matt Caswell <m...@openssl.org> wrote:
>
>
> On 16/09/2019 15:44, Peter Sui wrote:
> > Hi,
> > From the openssl website, I got the folloeing instruction:
> > "
> > Access to deprecated functions/macros has been removed by default. To
> enable
> > access you must do two things. 1) Build OpenSSL with deprecation support
> (pass
> > "enable-deprecated" as an argument to config) 2) Applications must define
> > "OPENSSL_USE_DEPRECATED" before including OpenSSL header files.
> > "
> > But, after I followed the instructions, it did not work. I searched all
> the
> > files(.h, .cpp, .c), I did not see the "OPENSSL_USE_DEPRECATED"
> anywhere. And
> > in the make file generated, I found it's using the
> > flag -D"_CRT_SECURE_NO_DEPRECATE", does it mean no deprecated functions
> > available in the library built? I also compared all the binary and
> header files
> > between the build without "enable-deprecated" and the build
> > with "enable-deprecated", there is no difference.
> > The command I used is:
> > perl Configure VC-WIN32 enable-deprecated
> > --prefix=T:\openssl-%OPENSSL_VERSION%-32bit-release-DLL-VS2015
> > nmake
> >
>
> That CHANGES entry is incorrect and out-of-date. It should probably be
> removed.
> The original CHANGES entry said this:
>
> *) config has been changed so that by default OPENSSL_NO_DEPRECATED is
> used.
> Access to deprecated functions can be re-enabled by running config
> with
> "enable-deprecated". In addition applications wishing to use
> deprecated
> functions must define OPENSSL_USE_DEPRECATED. Note that this new
> behaviour
> will, by default, disable some transitive includes that previously
> existed
> in the header files (e.g. ec.h will no longer, by default, include
> bn.h)
> [Matt Caswell]
>
> That CHANGES entry was added while 1.1.0 was being developed. However
> before
> 1.1.0 was released we changed our mind and added this CHANGES entry:
>
> *) Revert default OPENSSL_NO_DEPRECATED setting. Instead OpenSSL
> continues to support deprecated interfaces in default builds.
> However, applications are strongly advised to compile their
> source files with -DOPENSSL_API_COMPAT=0x10100000L, which hides
> the declarations of all interfaces deprecated in 0.9.8, 1.0.0
> or the 1.1.0 releases.
>
> In environments in which all applications have been ported to
> not use any deprecated interfaces OpenSSL's Configure script
> should be used with the --api=1.1.0 option to entirely remove
> support for the deprecated features from the library and
> unconditionally disable them in the installed headers.
> Essentially the same effect can be achieved with the "no-deprecated"
> argument to Configure, except that this will always restrict
> the build to just the latest API, rather than a fixed API
> version.
>
> As applications are ported to future revisions of the API,
> they should update their compile-time OPENSSL_API_COMPAT define
> accordingly, but in most cases should be able to continue to
> compile with later releases.
>
> The OPENSSL_API_COMPAT versions for 1.0.0, and 0.9.8 are
> 0x10000000L and 0x00908000L, respectively. However those
> versions did not support the OPENSSL_API_COMPAT feature, and
> so applications are not typically tested for explicit support
> of just the undeprecated features of either release.
> [Viktor Dukhovni]
>
> Regards
>
> Matt
>
