Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I5269be7d8e6c8ac399d86d9b48bfbd5cfabe0d19

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Signed-off-by: NHJ <huangjun42@huawei.com>

Description:openssl 1.1.1d used bu libhapverify
Team:OTHERS
Feature or Bugfix:Feature
Binary Source:Yes, it is
PrivateCode(Yes/No):No

Change-Id: I8968f9c0f146b587da17a3e603bd04fb7b4c505b
Reviewed-on: http://mgit-tm.rnd.huawei.com/7842784Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
Reviewed-by: Nhouyuezhou 00386575 <hou@huawei.com>
Reviewed-by: Nlinyibin 00246405 <linyibin@huawei.com>
Reviewed-by: Nweiping 00548480 <ping.wei@huawei.com>

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: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)

Since return is inconsistent, I removed unnecessary parentheses and
unified them.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4541)

Reviewed-by: NRichard 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: NViktor Dukhovni <viktor@openssl.org>

They all stop including evp_locl.h, so we also take care of their
adaptation to opaque EVP_CIPHER_CTX, as was promised in an earlier
commit.
Reviewed-by: NRich Salz <rsalz@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: NRich Salz <rsalz@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

underlying cipher to be size_t-fied, it allows for size_t, signed and
unsigned long. It maintains source and even binary compatibility.

        -Wmissing-prototypes -Wcomment -Wformat -Wimplicit -Wmain -Wmultichar
        -Wswitch -Wshadow -Wtrigraphs -Werror -Wchar-subscripts
        -Wstrict-prototypes -Wreturn-type -Wpointer-arith  -W -Wunused
        -Wno-unused-parameter -Wuninitialized

libdes (which is still used out there) or other des implementations,
the OpenSSL DES functions are renamed to begin with DES_ instead of
des_.  Compatibility routines are provided and declared by including
openssl/des_old.h.  Those declarations are the same as were in des.h
when the OpenSSL project started, which is exactly how libdes looked
at that time, and hopefully still looks today.

The compatibility functions will be removed in some future release, at
the latest in version 1.0.

Change the EVP_somecipher() and EVP_somedigest()
functions to return constant EVP_MD and EVP_CIPHER
pointers.

Update docs.

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.

Remove duplicated code in EVP.

Second phase of EVP cipher overhaul.

Change functions like EVP_EncryptUpdate() so they now return a
value. These normally have software only implementations
which cannot fail so this was acceptable. However ciphers
can be implemented in hardware and these could return errors.

Beginnings of EVP cipher overhaul. This should eventually
enhance and tidy up the EVP interface.

This patch adds initial support for variable length ciphers
and changes S/MIME code to use this.

Some other library functions need modifying to support use
of modified cipher parameters.

Also need to change all the cipher functions that should
return error codes, but currenly don't.

And of course it needs extensive testing...

Never use des_set_key (it depends on the global variable des_check_key),
but usually des_set_key_unchecked.
Only destest.c bothered to look at the return values of des_set_key,
but it did not set des_check_key -- if it had done so,
most checks would have failed because of wrong parity and
because of weak keys.

(meaning pointer to char) to des_cblock * (meaning pointer to
array with 8 char elements), which allows the compiler to
do more typechecking.  (The changed argument types were of type
des_cblock * back in SSLeay, and a lot of ugly casts were
used then to turn them into pointers to elements; but it can be
done without those casts.)

Introduce new type const_des_cblock -- before, the pointers rather
than the elements pointed to were declared const, and for
some reason gcc did not complain about this (but some other
compilers did).

Submitted by:
Reviewed by:
PR: