A local copy of OpenSSL from GitHub
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

3597 lines
132 KiB

Change the logic and behaviour surrounding '--api' and 'no-deprecated' At some point in time, there was a 'no-deprecated' configuration option, which had the effect of hiding all declarations of deprecated stuff, i.e. make the public API look like they were all removed. At some point in time, there was a '--api' configuration option, which had the effect of having the public API look like it did in the version given as value, on a best effort basis. In practice, this was used to get different implementations of BN_zero(), depending on the desired API compatibility level. At some later point in time, '--api' was changed to mean the same as 'no-deprecated', but only for the deprecations up to and including the desired API compatibility level. BN_zero() has been set to the pre-1.0.0 implementation ever since, unless 'no-deprecation' has been given. This change turns these options back to their original meaning, but with the slight twist that when combined, i.e. both '--api' and 'no-deprecated' is given, the declarations that are marked deprecated up to an including the desired API compatibility level are hidden, simulating that they have been removed. If no desired API compatibility level has been given, then configuration sets the current OpenSSL version by default. Furthermore, the macro OPENSSL_API_LEVEL is now used exclusively to check what API compatibility level is desired. For checking in code if `no-deprecated` has been configured for the desired API compatibility level, macros for each supported level is generated, such as OPENSSL_NO_DEPRECATED_1_1_1, corresponding to the use of DEPRECATEDIN_ macros, such as DEPRECATEDIN_1_1_1(). Just like before, to set an API compatibility level when building an application, define OPENSSL_API_COMPAT with an appropriate value. If it's desirable to hide deprecated functions up to and including that level, additionally define OPENSSL_NO_DEPRECATED (the value is ignored). Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10364)
2 years ago
23 years ago
Change the logic and behaviour surrounding '--api' and 'no-deprecated' At some point in time, there was a 'no-deprecated' configuration option, which had the effect of hiding all declarations of deprecated stuff, i.e. make the public API look like they were all removed. At some point in time, there was a '--api' configuration option, which had the effect of having the public API look like it did in the version given as value, on a best effort basis. In practice, this was used to get different implementations of BN_zero(), depending on the desired API compatibility level. At some later point in time, '--api' was changed to mean the same as 'no-deprecated', but only for the deprecations up to and including the desired API compatibility level. BN_zero() has been set to the pre-1.0.0 implementation ever since, unless 'no-deprecation' has been given. This change turns these options back to their original meaning, but with the slight twist that when combined, i.e. both '--api' and 'no-deprecated' is given, the declarations that are marked deprecated up to an including the desired API compatibility level are hidden, simulating that they have been removed. If no desired API compatibility level has been given, then configuration sets the current OpenSSL version by default. Furthermore, the macro OPENSSL_API_LEVEL is now used exclusively to check what API compatibility level is desired. For checking in code if `no-deprecated` has been configured for the desired API compatibility level, macros for each supported level is generated, such as OPENSSL_NO_DEPRECATED_1_1_1, corresponding to the use of DEPRECATEDIN_ macros, such as DEPRECATEDIN_1_1_1(). Just like before, to set an API compatibility level when building an application, define OPENSSL_API_COMPAT with an appropriate value. If it's desirable to hide deprecated functions up to and including that level, additionally define OPENSSL_NO_DEPRECATED (the value is ignored). Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10364)
2 years ago
Change the logic and behaviour surrounding '--api' and 'no-deprecated' At some point in time, there was a 'no-deprecated' configuration option, which had the effect of hiding all declarations of deprecated stuff, i.e. make the public API look like they were all removed. At some point in time, there was a '--api' configuration option, which had the effect of having the public API look like it did in the version given as value, on a best effort basis. In practice, this was used to get different implementations of BN_zero(), depending on the desired API compatibility level. At some later point in time, '--api' was changed to mean the same as 'no-deprecated', but only for the deprecations up to and including the desired API compatibility level. BN_zero() has been set to the pre-1.0.0 implementation ever since, unless 'no-deprecation' has been given. This change turns these options back to their original meaning, but with the slight twist that when combined, i.e. both '--api' and 'no-deprecated' is given, the declarations that are marked deprecated up to an including the desired API compatibility level are hidden, simulating that they have been removed. If no desired API compatibility level has been given, then configuration sets the current OpenSSL version by default. Furthermore, the macro OPENSSL_API_LEVEL is now used exclusively to check what API compatibility level is desired. For checking in code if `no-deprecated` has been configured for the desired API compatibility level, macros for each supported level is generated, such as OPENSSL_NO_DEPRECATED_1_1_1, corresponding to the use of DEPRECATEDIN_ macros, such as DEPRECATEDIN_1_1_1(). Just like before, to set an API compatibility level when building an application, define OPENSSL_API_COMPAT with an appropriate value. If it's desirable to hide deprecated functions up to and including that level, additionally define OPENSSL_NO_DEPRECATED (the value is ignored). Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10364)
2 years ago
Refactor file writing - introduce template driven file writing apps/CA.pl and tools/c_rehash are built from template files. So far, this was done by Configure, which created its own problems as it forced everyone to reconfigure just because one of the template files had changed. Instead, have those files created as part of the normal build in apps/ and in tools/. Furthermore, this prepares for a future where Configure may produce entirely other build files than Makefile, and the latter can't be guaranteed to be the holder of all information for other scripts. Instead, configdata.pm (described below) becomes the center of configuration information. This introduces a few new things: %config a hash table to hold all kinds of configuration data that can be used by any other script. configdata.pm a perl module that Configure writes. It currently holds the hash tables %config and %target. util/dofile.pl a script that takes a template on STDIN and outputs the result after applying configuration data on it. It's supposed to be called like this: perl -I$(TOP) -Mconfigdata < template > result or perl -I$(TOP) -Mconfigdata templ1 templ2 ... > result Note: util/dofile.pl requires Text::Template. As part of this changed, remove a number of variables that are really just copies of entries in %target, and use %target directly. The exceptions are $target{cflags} and $target{lflags}, they do get copied to $cflags and $lflags. The reason for this is that those variable potentially go through a lot of changes and would rather deserve a place in %config. That, however, is for another commit. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
7 years ago
Refactor file writing - introduce template driven file writing apps/CA.pl and tools/c_rehash are built from template files. So far, this was done by Configure, which created its own problems as it forced everyone to reconfigure just because one of the template files had changed. Instead, have those files created as part of the normal build in apps/ and in tools/. Furthermore, this prepares for a future where Configure may produce entirely other build files than Makefile, and the latter can't be guaranteed to be the holder of all information for other scripts. Instead, configdata.pm (described below) becomes the center of configuration information. This introduces a few new things: %config a hash table to hold all kinds of configuration data that can be used by any other script. configdata.pm a perl module that Configure writes. It currently holds the hash tables %config and %target. util/dofile.pl a script that takes a template on STDIN and outputs the result after applying configuration data on it. It's supposed to be called like this: perl -I$(TOP) -Mconfigdata < template > result or perl -I$(TOP) -Mconfigdata templ1 templ2 ... > result Note: util/dofile.pl requires Text::Template. As part of this changed, remove a number of variables that are really just copies of entries in %target, and use %target directly. The exceptions are $target{cflags} and $target{lflags}, they do get copied to $cflags and $lflags. The reason for this is that those variable potentially go through a lot of changes and would rather deserve a place in %config. That, however, is for another commit. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
7 years ago
Change the logic and behaviour surrounding '--api' and 'no-deprecated' At some point in time, there was a 'no-deprecated' configuration option, which had the effect of hiding all declarations of deprecated stuff, i.e. make the public API look like they were all removed. At some point in time, there was a '--api' configuration option, which had the effect of having the public API look like it did in the version given as value, on a best effort basis. In practice, this was used to get different implementations of BN_zero(), depending on the desired API compatibility level. At some later point in time, '--api' was changed to mean the same as 'no-deprecated', but only for the deprecations up to and including the desired API compatibility level. BN_zero() has been set to the pre-1.0.0 implementation ever since, unless 'no-deprecation' has been given. This change turns these options back to their original meaning, but with the slight twist that when combined, i.e. both '--api' and 'no-deprecated' is given, the declarations that are marked deprecated up to an including the desired API compatibility level are hidden, simulating that they have been removed. If no desired API compatibility level has been given, then configuration sets the current OpenSSL version by default. Furthermore, the macro OPENSSL_API_LEVEL is now used exclusively to check what API compatibility level is desired. For checking in code if `no-deprecated` has been configured for the desired API compatibility level, macros for each supported level is generated, such as OPENSSL_NO_DEPRECATED_1_1_1, corresponding to the use of DEPRECATEDIN_ macros, such as DEPRECATEDIN_1_1_1(). Just like before, to set an API compatibility level when building an application, define OPENSSL_API_COMPAT with an appropriate value. If it's desirable to hide deprecated functions up to and including that level, additionally define OPENSSL_NO_DEPRECATED (the value is ignored). Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10364)
2 years ago
11 years ago
Refactor file writing - introduce template driven file writing apps/CA.pl and tools/c_rehash are built from template files. So far, this was done by Configure, which created its own problems as it forced everyone to reconfigure just because one of the template files had changed. Instead, have those files created as part of the normal build in apps/ and in tools/. Furthermore, this prepares for a future where Configure may produce entirely other build files than Makefile, and the latter can't be guaranteed to be the holder of all information for other scripts. Instead, configdata.pm (described below) becomes the center of configuration information. This introduces a few new things: %config a hash table to hold all kinds of configuration data that can be used by any other script. configdata.pm a perl module that Configure writes. It currently holds the hash tables %config and %target. util/dofile.pl a script that takes a template on STDIN and outputs the result after applying configuration data on it. It's supposed to be called like this: perl -I$(TOP) -Mconfigdata < template > result or perl -I$(TOP) -Mconfigdata templ1 templ2 ... > result Note: util/dofile.pl requires Text::Template. As part of this changed, remove a number of variables that are really just copies of entries in %target, and use %target directly. The exceptions are $target{cflags} and $target{lflags}, they do get copied to $cflags and $lflags. The reason for this is that those variable potentially go through a lot of changes and would rather deserve a place in %config. That, however, is for another commit. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
7 years ago
Refactor file writing - introduce template driven file writing apps/CA.pl and tools/c_rehash are built from template files. So far, this was done by Configure, which created its own problems as it forced everyone to reconfigure just because one of the template files had changed. Instead, have those files created as part of the normal build in apps/ and in tools/. Furthermore, this prepares for a future where Configure may produce entirely other build files than Makefile, and the latter can't be guaranteed to be the holder of all information for other scripts. Instead, configdata.pm (described below) becomes the center of configuration information. This introduces a few new things: %config a hash table to hold all kinds of configuration data that can be used by any other script. configdata.pm a perl module that Configure writes. It currently holds the hash tables %config and %target. util/dofile.pl a script that takes a template on STDIN and outputs the result after applying configuration data on it. It's supposed to be called like this: perl -I$(TOP) -Mconfigdata < template > result or perl -I$(TOP) -Mconfigdata templ1 templ2 ... > result Note: util/dofile.pl requires Text::Template. As part of this changed, remove a number of variables that are really just copies of entries in %target, and use %target directly. The exceptions are $target{cflags} and $target{lflags}, they do get copied to $cflags and $lflags. The reason for this is that those variable potentially go through a lot of changes and would rather deserve a place in %config. That, however, is for another commit. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
7 years ago
Change the logic and behaviour surrounding '--api' and 'no-deprecated' At some point in time, there was a 'no-deprecated' configuration option, which had the effect of hiding all declarations of deprecated stuff, i.e. make the public API look like they were all removed. At some point in time, there was a '--api' configuration option, which had the effect of having the public API look like it did in the version given as value, on a best effort basis. In practice, this was used to get different implementations of BN_zero(), depending on the desired API compatibility level. At some later point in time, '--api' was changed to mean the same as 'no-deprecated', but only for the deprecations up to and including the desired API compatibility level. BN_zero() has been set to the pre-1.0.0 implementation ever since, unless 'no-deprecation' has been given. This change turns these options back to their original meaning, but with the slight twist that when combined, i.e. both '--api' and 'no-deprecated' is given, the declarations that are marked deprecated up to an including the desired API compatibility level are hidden, simulating that they have been removed. If no desired API compatibility level has been given, then configuration sets the current OpenSSL version by default. Furthermore, the macro OPENSSL_API_LEVEL is now used exclusively to check what API compatibility level is desired. For checking in code if `no-deprecated` has been configured for the desired API compatibility level, macros for each supported level is generated, such as OPENSSL_NO_DEPRECATED_1_1_1, corresponding to the use of DEPRECATEDIN_ macros, such as DEPRECATEDIN_1_1_1(). Just like before, to set an API compatibility level when building an application, define OPENSSL_API_COMPAT with an appropriate value. If it's desirable to hide deprecated functions up to and including that level, additionally define OPENSSL_NO_DEPRECATED (the value is ignored). Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10364)
2 years ago