RE: building openssl-1.1.1d with "enable-deprecated"

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: building openssl-1.1.1d with "enable-deprecated"

Peter Sui
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

Thank you inadvance!

Peter Sui

Reply | Threaded
Open this post in threaded view
|

Re: building openssl-1.1.1d with "enable-deprecated"

Matt Caswell-2


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
Reply | Threaded
Open this post in threaded view
|

Re: building openssl-1.1.1d with "enable-deprecated"

Michael Wojcik
In reply to this post by Peter Sui
Matt has answered the main question, but as an aside: -D"_CRT_SECURE_NO_DEPRECATE" suppresses warning messages from Microsoft's Visual C compiler for using various standard C library functions, rather than using the optional "secure" ones (a misnomer, as they are at best somewhat easier to use safely) added with C99 (in Appendix K of the C standard, I think; I'm traveling and don't have my copy handy). It has nothing to do with OpenSSL APIs, deprecated or otherwise; it just reduces noise from the Microsoft compiler.
Reply | Threaded
Open this post in threaded view
|

Re: building openssl-1.1.1d with "enable-deprecated"

Peter Sui
In reply to this post by Matt Caswell-2
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: building openssl-1.1.1d with "enable-deprecated"

Matt Caswell-2


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 <[hidden email]
> <mailto:[hidden email]>> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: building openssl-1.1.1d with "enable-deprecated"

Peter Sui
In reply to this post by Michael Wojcik
Hi Matt, 
       I said " It does not work" means, after I build the open-ssl1.1.1d with or without the "enable-deprecated" configuration, then use the library, header files in my application as before with the older version(1.0.2t), then my build failed, the errors are like:
Error C3861 'HMAC_CTX_init': identifier not found
Error C3861 'HMAC_CTX_cleanup': identifier not found
and more related to some struct def difference.
But as I imagine, it should not happen, right ? 

Peter

On Mon, Sep 16, 2019 at 11:17 AM Michael Wojcik <[hidden email]> wrote:
Matt has answered the main question, but as an aside: -D"_CRT_SECURE_NO_DEPRECATE" suppresses warning messages from Microsoft's Visual C compiler for using various standard C library functions, rather than using the optional "secure" ones (a misnomer, as they are at best somewhat easier to use safely) added with C99 (in Appendix K of the C standard, I think; I'm traveling and don't have my copy handy). It has nothing to do with OpenSSL APIs, deprecated or otherwise; it just reduces noise from the Microsoft compiler.
Reply | Threaded
Open this post in threaded view
|

Re: building openssl-1.1.1d with "enable-deprecated"

Matt Caswell-2


On 16/09/2019 16:26, Peter Sui wrote:
> Hi Matt, 
>        I said " It does not work" means, after I build the open-ssl1.1.1d with
> or without the "enable-deprecated" configuration, then use the library, header
> files in my application as before with the older version(1.0.2t), then my build
> failed, the errors are like:
> Error C3861 'HMAC_CTX_init': identifier not found
> Error C3861 'HMAC_CTX_cleanup': identifier not found
> and more related to some struct def difference.
> But as I imagine, it should not happen, right ?

Ah - right. I understand your problem.

1.1.x is not source compatible with 1.0.x regardless of enabling/disabling
deprecated functions. Some stuff just changed. Importantly most structures
became opaque, so it is no longer possible to access the internal fields.

An implication of this is that you can longer stack allocate objects based on
these structures any more (because the compiler knows nothing about the size of
the structure).

So instead of this:

        HMAC_CTX ctx;

You instead have to declare it as a pointer:

        HMAC_CTX *ctx;

Then you allocate a ctx like this:

        ctx = HMAC_CTX_new();

And later free it:

        HMAC_CTX_free();

The same thing applies to lots of other structures.

Since it is no longer possible to stack allocate an HMAC_CTX this makes
functions like HMAC_CTX_init() and HMAC_CTX_cleanup() redundant because they
only make sense when working with stack allocated structures - therefore they
were removed completely.

Matt

>
> Peter
>
> On Mon, Sep 16, 2019 at 11:17 AM Michael Wojcik <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Matt has answered the main question, but as an aside:
>     -D"_CRT_SECURE_NO_DEPRECATE" suppresses warning messages from Microsoft's
>     Visual C compiler for using various standard C library functions, rather
>     than using the optional "secure" ones (a misnomer, as they are at best
>     somewhat easier to use safely) added with C99 (in Appendix K of the C
>     standard, I think; I'm traveling and don't have my copy handy). It has
>     nothing to do with OpenSSL APIs, deprecated or otherwise; it just reduces
>     noise from the Microsoft compiler.
>