Skip to content

T
Third Party Openssl

OpenHarmony / Third Party Openssl
1 年多 前同步成功

通知 10
Star 18
Fork 1
T
Third Party Openssl
切换分支/标签
  1. 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
  3. 19 10月, 2018 8 次提交
  5. 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
  7. 17 10月, 2018 6 次提交
  9. 16 10月, 2018 3 次提交
  11. 15 10月, 2018 2 次提交
  13. 13 10月, 2018 5 次提交
  15. 12 10月, 2018 1 次提交
  17. 11 10月, 2018 1 次提交
  19. 10 10月, 2018 3 次提交
  21. 09 10月, 2018 1 次提交
    • B
      apps: allow empty attribute values with -subj · a7ee1ef6
      由 Benjamin Kaduk 提交于 
      Historically (i.e., OpenSSL 1.0.x), the openssl applications would
allow for empty subject attributes to be passed via the -subj argument,
e.g., `opensl req -subj '/CN=joe/O=/OU=local' ...`.  Commit
db4c08f0 applied a badly needed rewrite
to the parse_name() helper function that parses these strings, but
in the process dropped a check that would skip attributes with no
associated value.  As a result, such strings are now treated as
hard errors and the operation fails.

Restore the check to skip empty attribute values and restore
the historical behavior.

Document the behavior for empty subject attribute values in the
corresponding applications' manual pages.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7349)

(cherry picked from commit 3d362f190306b62a17aa2fd475b2bc8b3faa8142)
      a7ee1ef6
  23. 08 10月, 2018 1 次提交
  25. 06 10月, 2018 1 次提交
  27. 05 10月, 2018 1 次提交
  29. 04 10月, 2018 4 次提交