building openssl-1.1.1d with "enable-deprecated"

[Peter Sui]

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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190916/3a991d80/attachment-0001.html>