Previous macros suggested that from 3.0, we're only allowed to
deprecate things at a major version. However, there's no policy
stating this, but there is for removal, saying that to remove
something, it must have been deprecated for 5 years, and that removal
can only happen at a major version.
Meanwhile, the semantic versioning rule is that deprecation should
trigger a MINOR version update, which is reflected in the macro names
as of this change.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10364)
Make the include guards consistent by renaming them systematically according
to the naming conventions below
For the public header files (in the 'include/openssl' directory), the guard
names try to match the path specified in the include directives, with
all letters converted to upper case and '/' and '.' replaced by '_'. For the
private header files files, an extra 'OSSL_' is added as prefix.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9333)
Run perltidy on util/mkerr
Change some mkerr flags, write some doc comments
Make generated tables "const" when genearting lib-internal ones.
Add "state" file for mkerr
Renerate error tables and headers
Rationalize declaration of ERR_load_XXX_strings
Fix out-of-tree build
Add -static; sort flags/vars for options.
Also tweak code output
Moved engines/afalg to engines (from master)
Use -static flag
Standard engine #include's of errors
Don't linewrap err string tables unless necessary
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3392)
The ossltest engine wraps the built-in implementation of aes128-cbc.
Normally in an engine the cipher_data structure is automatically allocated
by the EVP layer. However this relies on the engine specifying up front
the size of that cipher_data structure. In the case of ossltest this value
isn't available at compile time. This change makes the ossltest engine
allocate its own cipher_data structure instead of leaving it to the EVP
layer.
Reviewed-by: Andy Polyakov <appro@openssl.org>
This engine is for testing purposes only. It provides crippled crypto
implementations and therefore must not be used in any instance where
security is required.
This will be used by the forthcoming libssl test harness which will operate
as a man-in-the-middle proxy. The test harness will be able to modify
TLS packets and read their contents. By using this test engine packets are
not encrypted and MAC codes always verify.
Reviewed-by: Richard Levitte <levitte@openssl.org>
