Skip to content

T
Third Party Openssl

OpenHarmony / Third Party Openssl
10 个月 前同步成功

通知 8
Star 18
Fork 1
T
Third Party Openssl

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

切换分支/标签
  1. 29 10月, 2018 8 次提交
  3. 28 10月, 2018 1 次提交
  5. 27 10月, 2018 3 次提交
    • B
      Fix data race in RAND_DRBG_generate · 1f985276
      由 Bernd Edlinger 提交于 
      Fixes #7394
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7399)

(cherry picked from commit a83dc59afa2e0207180d7218efed19b20d48de95)
      1f985276
    • D
      RAND_add()/RAND_seed(): fix failure on short input or low entropy · d597a9a8
      由 Dr. Matthias St. Pierre 提交于 
      Commit 5b4cb385c18a (#7382) introduced a bug which had the effect
that RAND_add()/RAND_seed() failed for buffer sizes less than
32 bytes. The reason was that now the added random data was used
exlusively as entropy source for reseeding. When the random input
was too short or contained not enough entropy, the DRBG failed
without querying the available entropy sources.

This commit makes drbg_add() act smarter: it checks the entropy
requirements explicitely. If the random input fails this check,
it won't be added as entropy input, but only as additional data.
More precisely, the behaviour depends on whether an os entropy
source was configured (which is the default on most os):

- If an os entropy source is avaible then we declare the buffer
  content as additional data by setting randomness to zero and
  trigger a regular   reseeding.

- If no os entropy source is available, a reseeding will fail
  inevitably. So drbg_add() uses a trick to mix the buffer contents
  into the DRBG state without forcing a reseeding: it generates a
  dummy random byte, using the buffer content as additional data.

Related-to: #7449
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7456)

(cherry picked from commit 8817215d5c52a76f2b184b624bde4df8556dee6d)
      d597a9a8
    • D
      Backport some DRBG renamings and typo fixes · 35a34508
      由 Dr. Matthias St. Pierre 提交于 
      In commit 8bf366519661 some renamings andd typo fixes were made
while adding back the DRBG-HMAC and DRBG-HASH implementation.
Since the commit could not be backported, a lot of unnecessary
differences between master and 1.1.1 were introduced.

These differences result in tiresome merge conflicts when
cherry-picking. To minimize these merge-conflicts, this patch
ports all 'non-feature' changes of commit 8bf366519661
(e.g., renamings of private variables, fixes of typographical
errors, comment changes) manually back to 1.1.1.

The commits a83dc59afa2e (#7399) and 8817215d5c52 (#7456)
failed to cherry-pick previously to 1.1.1, with this patch
they both cherry-pick without conflicts.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/7505)
      35a34508
  7. 26 10月, 2018 7 次提交
  9. 23 10月, 2018 1 次提交
  11. 22 10月, 2018 1 次提交
    • D
      RAND_add(): fix heap corruption in error path · ece482ff
      由 Dr. Matthias St. Pierre 提交于 
      This bug was introduced by #7382 which enhanced RAND_add() to
accept large buffer sizes. As a consequence, RAND_add() now fails
for buffer sizes less than 32 bytes (i.e. less than 256 bits).
In addition, rand_drbg_get_entropy() forgets to reset the attached
drbg->pool in the case of an error, which leads to the heap corruption.

The problem occurred with RAND_load_file(), which reads the file in
chunks of 1024 bytes each. If the size of the final chunk is less than
32 bytes, then RAND_add() fails, whence RAND_load_file() fails
silently for buffer sizes n = k * 1024 + r with r = 1,...,31.

This commit fixes the heap corruption only. The other issues will
be addressed in a separate pull request.

Thanks to Gisle Vanem for reporting this issue.

Fixes #7449
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7455)

(cherry picked from commit 5b4cb385c18a5bb4e118e300f1c746bf7c2a5628)
      ece482ff
  13. 21 10月, 2018 1 次提交
    • R
      build file templates: have targets for all shared library names · 132fd512
      由 Richard Levitte 提交于 
      We only had targets for the "simple" shared library names (libfoo.so
and not libfoo.so.x.y on Unix, import library libfoo.lib but not
libfoo.dll on Windows).  This has created some confusion why it wasn't
possible to rebuild the less "simple" name directly (just as an
example, someone who mistook the import library on Windows for a
static library, removed the DLL and then found it was difficult to
rebuild directly), so we change the target to include all possible
names.
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7451)

(cherry picked from commit d8cac50b023be249cdaba054f43acecf17025ce4)
      132fd512
  15. 19 10月, 2018 8 次提交
  17. 18 10月, 2018 2 次提交
    • V
      Apply self-imposed path length also to root CAs · a190ea8a
      由 Viktor Dukhovni 提交于 
      Also, some readers of the code find starting the count at 1 for EE
cert confusing (since RFC5280 counts only non-self-issued intermediate
CAs, but we also counted the leaf).  Therefore, never count the EE
cert, and adjust the path length comparison accordinly.  This may
be more clear to the reader.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(cherry picked from commit dc5831da59e9bfad61ba425d886a0b06ac160cd6)
      a190ea8a
    • V
      Only CA certificates can be self-issued · bb692394
      由 Viktor Dukhovni 提交于 
      At the bottom of https://tools.ietf.org/html/rfc5280#page-12 and
top of https://tools.ietf.org/html/rfc5280#page-13 (last paragraph
of above https://tools.ietf.org/html/rfc5280#section-3.3), we see:

   This specification covers two classes of certificates: CA
   certificates and end entity certificates.  CA certificates may be
   further divided into three classes: cross-certificates, self-issued
   certificates, and self-signed certificates.  Cross-certificates are
   CA certificates in which the issuer and subject are different
   entities.  Cross-certificates describe a trust relationship between
   the two CAs.  Self-issued certificates are CA certificates in which
   the issuer and subject are the same entity.  Self-issued certificates
   are generated to support changes in policy or operations.  Self-
   signed certificates are self-issued certificates where the digital
   signature may be verified by the public key bound into the
   certificate.  Self-signed certificates are used to convey a public
   key for use to begin certification paths.  End entity certificates
   are issued to subjects that are not authorized to issue certificates.

that the term "self-issued" is only applicable to CAs, not end-entity
certificates.  In https://tools.ietf.org/html/rfc5280#section-4.2.1.9
the description of path length constraints says:

   The pathLenConstraint field is meaningful only if the cA boolean is
   asserted and the key usage extension, if present, asserts the
   keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
   maximum number of non-self-issued intermediate certificates that may
   follow this certificate in a valid certification path.  (Note: The
   last certificate in the certification path is not an intermediate
   certificate, and is not included in this limit.  Usually, the last
   certificate is an end entity certificate, but it can be a CA
   certificate.)

This makes it clear that exclusion of self-issued certificates from
the path length count applies only to some *intermediate* CA
certificates.  A leaf certificate whether it has identical issuer
and subject or whether it is a CA or not is never part of the
intermediate certificate count.  The handling of all leaf certificates
must be the same, in the case of our code to post-increment the
path count by 1, so that we ultimately reach a non-self-issued
intermediate it will be the first one (not zeroth) in the chain
of intermediates.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(cherry picked from commit ed422a2d0196ada0f5c1b6e296f4a4e5ed69577f)
      bb692394
  19. 17 10月, 2018 6 次提交
  21. 16 10月, 2018 2 次提交