| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Delete some code from X509_TRUST_cleanup(3) that had no effect:
it called a function on static objects that returns right away
unless the argument is dynamically allocated.
Pointed out by tb@.
This commit is identical to:
OpenSSL commit 5e6e650d62af09f47d63bfdd6c92e3b16e9da644
Author: Kurt Cancemi <kurt at x64architecture dot com>
Date: Thu Jun 9 21:57:36 2016 -0400
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it called a function on static objects that returns right away
unless the argument is dynamically allocated.
OK jsing@ tb@
The useless code was independently discovered while writing documentation.
This commit is identical to:
OpenSSL commit fa3a0286d178eb3b87bf2eb5fd7af40f81453314
Author: Kurt Cancemi <kurt at x64architecture dot com>
Date: Wed Jun 8 19:15:38 2016 -0400
|
|
|
|
|
|
| |
intentionally undocumented because it uses MD5 only and is
unused in real-world code according to codesearch.debian.net.
No objection from tb@.
|
| |
|
| |
|
|
|
|
| |
been defined or user-supplied checking functions may have been installed
|
|
|
|
| |
related to X509_PURPOSE objects, purpose identifiers, and purpose indices
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Fix the order of functions to match the order they occur in
application code, making the text significantly easier to follow.
2. Do not use the same argument placeholder *sk for several different
things; call the arguments *trusted, *untrusted, and *crls as
appropriate.
3. Avoid using the word "initialised" for two different concepts
in the same manual page; it was sometimes intended to mean "fill
with zeros" and sometimes "replace the zeros with useful data".
4. Generally, make the text more precise, more straightforward,
and shorter (-84 +65 lines of mdoc code).
|
|
|
|
|
|
|
|
|
| |
of X509_STORE_CTX_new(3) because i'm about to document five additional
functions of this kind and the page X509_STORE_CTX_new(3) is growing
unwieldy.
No text change yet, except that i added an introductory sentence
to the beginning of the DESCRIPTION of the new page.
|
|
|
|
| |
and X509_STORE_CTX_get0_current_crl(3)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenSSL documents it in X509_STORE_CTX_get_error(3), but it is
misplaced there. It has nothing to do with accessing status or
error information but merely retrieves a pointer to the certificate
that the users wants to validate. It is a companion function to
X509_STORE_CTX_init(3), X509_STORE_CTX_set_cert(3),
X509_STORE_CTX_get0_store(3), and X509_STORE_CTX_get0_untrusted(3).
While here:
1. Clarify how the new, init, verify, cleanup, and free calls interact,
and who owns the memory involved, because this is all really confusing
from the user perspective.
2. Clarify how X509_STORE_CTX_init(3), X509_STORE_CTX_set_cert(3), and
X509_STORE_CTX_set_chain(3) partially override each other.
3. Move X509_STORE_CTX_set0_untrusted(3) to the proper place because
it is the same as X509_STORE_CTX_set_chain(3).
4. Add a few missing words and improve some wordings.
|
|
|
|
|
| |
It is deprecated, but it is still called by various application programs,
so let's better mention it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When DTLS handshake records are received from the next epoch, we will
potentially queue them on the unprocessed_rcds queue - this is usually
a Finished message that has been received without the ChangeCipherSuite
(CCS) message (which may have been dropped or reordered).
After the epoch increments (due to the CCS being received), the current
code processes all records on the unprocessed queue and immediate queues
them on the processed queue, which dtls1_get_record() then pulls from.
This form of processing only adds more complexity and another queue.
Instead, once the epoch increments, pull a single record from the
unprocessed queue and process it, allowing the contents to be consumed
by the caller. We repeat this process until the unprocessed queue is
empty, at which point we go back to consuming messages from the wire.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
|
| |
Per RFC 6347 section 4.1.2.1, DTLS should silently discard invalid records,
including those that have a bad MAC. When converting to the new record
layer, we inadvertantly switched to standard TLS behaviour, where an
invalid record is fatal. This restores the previous behaviour.
Issue noted by inoguchi@
ok inoguchi@
|
|
|
|
|
|
|
|
|
|
| |
X509_issuer_name_hash(3), X509_subject_name_hash(3), and the _old variants.
Even though this is only tangentially related to decoding and encoding,
including a single function in d2i_X509_NAME(3) was probably OK,
but let's not bog down that page with six functions that are likely
to become obsolete at some point - even though right now, they are
still being used both internally and by external software.
|
|
|
|
| |
missed with r1.32
|
| |
|
|
|
|
|
|
|
|
| |
All this code does is read one byte from memory with an unknown length,
potentially being a one byte overread... and then nothing is actually done
with the value.
ok tb@
|
|
|
|
| |
ok tb@
|
| |
|
| |
|
| |
|
|
|
|
| |
input from jsing@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New option handling for openssl(1) ca.
This diff is just replacing with new option handling, no functional change.
I'm using the word DN or RDN in description as manual uses them, rather than
replacing with "Distinguished Name" or "Relative Distinguished Name".
I would like to add another fixes below by follow-up diffs.
- remove space between '*' and pointer variable
- wrap 80+ long lines
- explicitly check pointer variable if it is NULL or not
comments and ok from jsing@
|
|
|
|
|
|
|
|
|
|
|
|
| |
As per the manual and lib/libtls/tls.c revision 1.79 from 2018
"Automatically handle library initialisation for libtls." initialisation
is handled automatically by other tls_*(3) functions.
Remove explicit tls_init() calls from base to not give the impression of
it being needed.
Feedback tb
OK Tests mestre
|
| |
|
|
|
|
|
|
|
| |
calling the OpenSSL legacy cache extensions goo.
Requested by tb@
ok tb@
|
|
|
|
|
|
|
|
|
| |
fails to report the path that the failure occured on. Suggested by
deraadt@ after some tech discussion.
Work done and verified by Ashton Fagg <ashton@fagg.id.au>
ok deraadt@ semarie@ claudio@
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
is pure comedy gold, and now documented as such, sadly this bit of pure
Muppet genius can't really in good consience stay in the tree as is.
Change BIO_dump to always return the number of bytes printed on success
and to stop printing and return -1 on failure if a writing function
fails.
ok tb@, jsing@
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which by implication also affects X509_print(3).
The ASN1_STRING_get0_data(3) manual explitely cautions the reader
that the data is not necessarily NUL-terminated, and the function
X509_alias_set1(3) does not sanitize the data passed into it in
any way either, so we must assume the alias->data field is merely
a byte array and not necessarily a string in the sense of the C
language.
I found this bug while writing manual pages for these functions.
OK tb@
As an aside, note that the function still produces incomplete and
misleading results when the data contains a NUL byte in the middle
and that error handling is consistently absent throughout, even
though the function provides an "int" return value obviously intended
to be 1 for success and 0 for failure, and even though this function
is called by another function that also wants to return 1 for success
and 0 for failure and even does so in many of its code paths, though
not in others. But let's stay focussed. Many things would be nice
to have in the wide wild world, but a buffer overflow must not be
allowed to remain in our backyard.
|
| |
|
|
|
|
|
|
|
|
|
| |
the saving of the first error case so that the "autochain" craziness from
openssl will work with the new verifier. This should allow the new verification
code to work with a bunch of the autochain using cases in some software.
(and should allow us to stop using the legacy verifier with autochain)
ok tb@
|
|
|
|
| |
"please commit" schwarze
|
| |
|
|
|
|
| |
X509_alias_set1(3), X509_alias_get0(3)
|
| |
|
| |
|
| |
|
|
|
|
| |
suggested by millert@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the user set nmflags == X509_FLAG_COMPAT and X509_NAME_print_ex(3)
failed, the error return value of 0 was misinterpreted as an indicator
of success, causing X509_print_ex(3) to ignore the error, continue
printing, and potentially return successfully even though not all
the content of the certificate was printed.
The X509_NAME_print_ex(3) manual page explains that this function
indicates failure by returning 0 if nmflags == X509_FLAG_COMPAT
and by returning -1 if nmflags != X509_FLAG_COMPAT.
That's definitely atrocious API design (witnessed by the
complexity of the code needed for correct error checking),
but changing the API contract and becoming incompatible
with OpenSSL would make matters even worse.
Note that just checking for <= 0 in all cases would not be correct
either because X509_NAME_print_ex(3) returns 0 to indicate that it
successfully printed zero bytes in some cases, for example when all
three of the following conditions hold:
1. nmflags != X509_FLAG_COMPAT
2. indent == 0 (which X509_print_ex(3) does use in some cases)
3. the name object is NULL or empty
I found the bug by code inspection and proposed an incomplete patch,
then jsing@ proposed this improved version of the patch.
OK jsing@.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
even though it did not actually set the name.
Instead, indicate failure in this case.
This commit sneaks in a small, unrelated change in behaviour.
If the first argument of X509_NAME_set(3) was NULL, the function
used to return failure. Now it crashes the program by accessing
the NULL pointer, for compatibility with the same change in OpenSSL.
This merges the following two commits from the OpenSSL-1.1.1 branch,
which is still available under a free license:
1. 180794c5 Rich Salz Sep 3 11:33:34 2017 -0400
2. c1c1783d Richard Levitte May 17 09:53:14 2018 +0200
OK tb@
|
|
|
|
|
|
| |
It is not particularly well-designed and sets a number of traps for the
unwary, but it is a public API function in both OpenSSL and LibreSSL
and used at various places.
|