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 <matt@xxxxxxxxxxx> 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
