| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
3rd (variadic) mode_t parameter is irrelevant. Many developers in the past
have passed mode_t (0, 044, 0644, or such), which might lead future people
to copy this broken idiom, and perhaps even believe this parameter has some
meaning or implication or application. Delete them all.
This comes out of a conversation where tb@ noticed that a strange (but
intentional) pledge behaviour is to always knock-out high-bits from
mode_t on a number of system calls as a safety factor, and his bewilderment
that this appeared to be happening against valid modes (at least visually),
but no sorry, they are all irrelevant junk. They could all be 0xdeafbeef.
ok millert
|
|
|
|
| |
ok beck jsing
|
|
|
|
| |
ok beck jsing
|
|
|
|
| |
ok beck jsing
|
|
|
|
| |
ok beck jsing
|
|
|
|
| |
ok beck jsing
|
|
|
|
|
|
|
|
|
|
|
| |
and since CMS_ReceiptRequest_get0_values(3) uses it, add it to the
list of STACK_OF(3) types.
While here, also add the missing CMS_RecipientInfo, CMS_SignerInfo,
OPENSSL_STRING, SRTP_PROTECTION_PROFILE, SSL_CIPHER, SSL_COMP and
X509_NAME to the list of stack types used by the API, drop
STACK_OF(X509_PURPOSE) which is only used internally, and list those
STACK_OF(*) types separately that are obfuscated with typedef.
|
|
|
|
| |
ok beck inoguchi jsing
|
| |
|
|
|
|
| |
ok jsing
|
| |
|
| |
|
|
|
|
|
|
|
| |
X509_get_extended_key_usage from OpenSSL. Will be linked to the build
after the bump.
input/lgtm schwarze
|
|
|
|
|
|
| |
to the build after the bump.
tweak & lgtm schwarze
|
|
|
|
| |
and fix some weird typos in comments (duplicate '@' signs)
|
|
|
|
| |
ok beck jsing
|
|
|
|
| |
ok beck jsing
|
|
|
|
| |
ok beck jsing
|
|
|
|
| |
ok beck jsing
|
|
|
|
|
| |
Symbols.list changes to follow with tb's upcoming bump
ok jsing@
|
|
|
|
| |
ok beck jsing
|
|
|
|
|
|
| |
Prompted by a diff by Jonas Termansen.
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
for associating X.501 Attributes with private keys
|
|
|
|
| |
describing five functions to change arrays of X.501 Attribute objects
|
| |
|
|
|
|
| |
documenting five X.501 Attribute read accessors
|
|
|
|
|
|
| |
After tb@'s commit x509/x509_lu.c rev. 1.33, it is no longer necessary
to talk about X509_LU_* constants as return values from these functions.
Feedback and OK from tb@.
|
|
|
|
|
|
|
| |
that we know that it only returns 0 or 1. Eliminate the last uses
of X509_LU_{FAIL,RETRY}.
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
documenting five X.501 Attribute write accessors
|
|
|
|
|
|
|
|
|
|
|
| |
Initialize stmp.type and stmp.data.ptr so that a user-defined lookup
method need not take responsibility of initializing those. Get rid of
current_method, which was never really used. Stop potentially returning
a negative value since most callers assume Boolean return values already.
In addition, garbage collect the pointless j variable.
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
|
|
|
| |
extension. This is part of OpenSSL commit df4c395c which didn't make
it into our tree for some reason.
ok jsing
|
|
|
|
| |
ok jsing
|
| |
|
|
|
|
| |
and the three functions related to the global mask
|
|
|
|
| |
also documenting ASN1_mbstring_ncopy(3)
|
|
|
|
| |
documenting the four X.501 Attribute read accessors
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
is becoming excessively long, into a new page X509_VERIFY_PARAM_new(3);
no content change
|
|
|
|
| |
else in libcrypto's manuals and headers).
|
|
|
|
|
|
|
|
| |
for a NULL ctx->ctx in the lookup functions using X509_STORE_CTX.
This affects X509_STORE_get1_certs(), X509_STORE_get1_crls(),
X509_STORE_CTX_get1_issuer() and X509_STORE_get_by_subject().
With this X509_verify_cert() no longer crashes with a NULL store.
With and OK tb@
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to work around the expired DST Root CA X3 certficiate, enable
X509_V_FLAG_TRUSTED_FIRST in the legacy verifier. This means that the
default chain provided by Let's Encrypt will stop at the ISRG Root X1
intermediate, rather than following the DST Root CA X3 intermediate.
Note that the new verifier does not suffer from this issue, so only a
small number of things will hit this code path.
ok millert@ robert@ tb@
|