building openssl-1.1.1d with "enable-deprecated"

[Matt Caswell]

On 16/09/2019 16:09, Peter Sui wrote:
> 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 ?

Right.

> If yes, then in my application , if  I have "OPENSSL_USE_DEPRECATED"
> defined, the depecated functions in my application should still work, right? 

You don't need OPENSSL_USE_DEPRECATED at all. All of that code was removed when
we changed our mind. It doesn't exist at all in the codebase today.

> But it does not work.

What exactly does not work? What function are you trying to call?

Matt

> 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 at openssl.org
> <mailto:matt at 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
>