| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
* mururu/fix-type:
Fix typos in the public_key doc
OTP-12549
|
|
|
|
|
|
|
|
See #535
Signed-off-by: Peter Lemenkov <[email protected]>
|
|
|
|
|
|
|
|
Check that the certificate chain ends with a trusted ROOT CA e.i. a
self-signed certificate, but provide an option partial_chain to
enable the application to define an intermediat CA as trusted.
TLS RFC says:
"unknown_ca
A valid certificate chain or partial chain was received, but the
certificate was not accepted because the CA certificate could not
be located or couldn't be matched with a known, trusted CA. This
message is always fatal."
and also states:
"certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case."
X509 RFC says:
"The selection of a trust anchor is a matter of policy: it could be
the top CA in a hierarchical PKI, the CA that issued the verifier's
own certificate(s), or any other CA in a network PKI. The path
validation procedure is the same regardless of the choice of trust
anchor. In addition, different applications may rely on different
trust anchors, or may accept paths that begin with any of a set of
trust anchors."
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Handle v1 CRLs, with no extensions.
* Compare the IDP on a CRL correctly, if present
* Don't try to double-decode altnames
Tests are also included, and the make_certs testing tool in the SSL
application has been greatly extended.
|
|
|
|
Most dependencies introduced are exactly the dependencies to other
applications found by xref. That is, there might be real dependencies
missing. There might also be pure debug dependencies listed that
probably should be removed. Each application has to be manually
inspected in order to ensure that all real dependencies are listed.
All dependencies introduced are to application versions used in
OTP 17.0. This since the previously used version scheme wasn't
designed for this, and in order to minimize the work of introducing
the dependencies.
|
|
Ensure all are "normal" versions according to the new version scheme
introduced in OTP 17.0
|
|
Add the mentioned test suites for *all* library and touched
non-library applications.
|
|
As discussed in issue #240 *all* OTP library applications use the '.*'
wildcard as up and down version. This makes library applications
always up- and downgradeable. Using the wildcard version obsoletes
all maintenance tasks regarding library applications' appup files.
Additionally, it prevents upgrade problems caused by automatically
included application dependencies when using reltool to create
releases. Missing copyright headers are now consistently present.
|
|
* tuncer/fix-public_key-specs:
public_key(3): fix private_key/0 type definition
OTP-11627
|
|
|
|
Move dilayzer types from include file to erl file and use
-export_type
|
|
When documenting public_key/0 and private_key/0, I noticed the
inconsistent state of formatting in public_key(3)'s Data Types section.
This should be fixed for consistency and readability.
|
|
public_key:private_key/0 was referenced but undefined, and lib/ssl had a
local definition of private_key/0.
To fix that, make the following changes:
* add public_key:private_key/0 type
* document public_key/0 and private_key/0
* fix incorrect definitions and references
|
|
ssh and public_key were referring to proplists:proplists/0
which does not exist. Fix by using the correct type proplists:proplist/0.
|
|
|
|
The R16B03 release
Conflicts:
lib/sasl/vsn.mk
|
|
|
|
|
|
|
|
|
|
|
|
Author: Daniel Barney <[email protected]>
Date: Thu Oct 25 14:33:11 2012 -0600
Most common browsers are lax in thier handling of how the
emailAddress field is encoded. RFC 3280 section 4.1.2.6
defines the encoding as IA5String, however browsers will
also handle certificates with the emailAddress field
encoded as UTF8String. This fix allows the emailAddress
to be decoded as both an IA5String and an UTF8String.
Reviewed by: Andrew Bennett <[email protected]>
|
|
|
|
|
|
In the example of `public_key:pem_entry_encode/2`, the result
should match to `PemEntry` rather than to `PemBin` since `PemEntry`
is expected as an input argument of `public_key:pem_encode/1` called
just on the next line of the example.
|
|
The R16B02 release
Conflicts:
lib/sasl/vsn.mk
|
