Currently, there are two different directories which contain internal
header files of libcrypto which are meant to be shared internally:
While header files in 'include/internal' are intended to be shared
between libcrypto and libssl, the files in 'crypto/include/internal'
are intended to be shared inside libcrypto only.
To make things complicated, the include search path is set up in such
a way that the directive #include "internal/file.h" could refer to
a file in either of these two directoroes. This makes it necessary
in some cases to add a '_int.h' suffix to some files to resolve this
ambiguity:
#include "internal/file.h" # located in 'include/internal'
#include "internal/file_int.h" # located in 'crypto/include/internal'
This commit moves the private crypto headers from
'crypto/include/internal' to 'include/crypto'
As a result, the include directives become unambiguous
#include "internal/file.h" # located in 'include/internal'
#include "crypto/file.h" # located in 'include/crypto'
hence the superfluous '_int.h' suffixes can be stripped.
The files 'store_int.h' and 'store.h' need to be treated specially;
they are joined into a single file.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)
Support added for these two digests, available only via the EVP interface.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5093)
SM3 is a secure hash function which is part of the Chinese
"Commercial Cryptography" suite of algorithms which use is
required for certain commercial applications in China.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4616)
There is a preference for suffixes to indicate that a function is internal
rather than prefixes. Note: the suffix is only required to disambiguate
internal functions and public symbols with the same name (but different
case)
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
There was a lot of naming inconsistency, so we try and standardise on
one form.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
This was done by the following
find . -name '*.[ch]' | /tmp/pl
where /tmp/pl is the following three-line script:
print unless $. == 1 && m@/\* .*\.[ch] \*/@;
close ARGV if eof; # Close file to reset $.
And then some hand-editing of other files.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Remove sign/verify and required_pkey_type fields of EVP_MD: these are a
legacy from when digests were linked to public key types. All signing is
now handled by the corresponding EVP_PKEY_METHOD.
Only allow supported digest types in RSA EVP_PKEY_METHOD: other algorithms
already block unsupported types.
Remove now obsolete EVP_dss1() and EVP_ecdsa().
Reviewed-by: Richard Levitte <levitte@openssl.org>
There are header files in crypto/ that are used by a number of crypto/
submodules. Move those to crypto/include/internal and adapt the
affected source code and Makefiles.
The header files that got moved are:
crypto/cryptolib.h
crypto/md32_common.h
Reviewed-by: Rich Salz <rsalz@openssl.org>
Remove support for SHA0 and DSS0 (they were broken), and remove
the ability to attempt to build without SHA (it didn't work).
For simplicity, remove the option of not building various SHA algorithms;
you could argue that SHA_224/256/384/512 should be kept, since they're
like crypto algorithms, but I decided to go the other way.
So these options are gone:
GENUINE_DSA OPENSSL_NO_SHA0
OPENSSL_NO_SHA OPENSSL_NO_SHA1
OPENSSL_NO_SHA224 OPENSSL_NO_SHA256
OPENSSL_NO_SHA384 OPENSSL_NO_SHA512
Reviewed-by: Richard Levitte <levitte@openssl.org>
OPENSSL_NO_RIPEMD160, OPENSSL_NO_RIPEMD merged into OPENSSL_NO_RMD160
OPENSSL_NO_FP_API merged into OPENSSL_NO_STDIO
Two typo's on #endif comments fixed:
OPENSSL_NO_ECB fixed to OPENSSL_NO_OCB
OPENSSL_NO_HW_SureWare fixed to OPENSSL_NO_HW_SUREWARE
Reviewed-by: Richard Levitte <levitte@openssl.org>
sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.
I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.
