| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
The only real difference between BN_cmp() and BN_ucmp() is that one has
to respect the sign of the BN (although BN_cmp() also gets to deal with
some insanity from accepting NULLs). Rewrite/cleanup BN_ucmp() and turn
BN_cmp() into code that handles differences in sign, before calling
BN_ucmp().
ok tb@
|
|
|
|
|
|
| |
Also be more consistent with variable naming.
ok tb@
|
|
|
|
| |
ok tb@
|
|
|
|
| |
ok tb@
|
|
|
|
|
|
|
| |
Remove a comment that tells you not to call a function that internally
calls free, with a stack allocated pointer...
ok tb@
|
|
|
|
|
|
|
| |
Nothing can be actually using these as the symbols are not exported from
libcrypto... hopefully ui_compat.h can also go away entirely.
ok tb@
|
| |
|
|
|
|
| |
OK tb@
|
|
|
|
|
|
|
|
| |
Ben Laurie invented the system logging BIO in 1999 and yet,
nothing whatsoever uses it according to codesearch.debian.net.
Besides, it is poorly designed and a crypto library is absolutely
not the place for putting a clumsy system logging facility.
Not everything needs to be a BIO!
|
|
|
|
|
|
|
|
|
|
|
| |
as intentionally undocumented.
Bodo Moeller invented this "non-copying I/O" API in 1999, but according
to codesearch.debian.net, it is still completely unused by anything.
On top of that, it appears to be inflexible in so far as it only
supports BIO pairs and no other BIO types and fragile in so far as
it exposes pointers to internal storage and runs contrary to expectations
of how BIO objects are supposed to work.
|
|
|
|
|
|
| |
It appears Richard Levitte succumbed to everything-needs-a-callback-paranoia
in 2004, but nobody is going to be surprised that nothing whatsoever wants
to use this particular callback, according to codesearch.debian.net.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
BIO_set_retry_special(3), BIO_clear_retry_flags(3), BIO_get_retry_flags(3),
and the BIO_FLAGS_* constants
|
| |
|
| |
|
|
|
|
|
| |
from Richard Levitte via OpenSSL commit 0e474b8b in the 1.1.1 branch,
which is still under a freee license
|
| |
|
|
|
|
|
|
| |
jsing doesn't like it, but it's better than nothing.
ok jsing
|
|
|
|
| |
and BIO_get_flags(3).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
xmlsec needs this, nothing else. Our linkers link libxmlsec1-openssl,
only warns and since nothing uses this library in ports, this wasn't
noticed for a long time.
Reported by Thomas Mitterfellner
ok jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BN_zero() is currently implemented using BN_set_word(), which means it can
fail, however almost nothing ever checks the return value. A long time
ago OpenSSL changed BN_zero() to always succeed and return void, however
kept BN_zero as a macro that calls a new BN_zero_ex() function, so that
it can be switched back to the "can fail" version.
Take a simpler approach - change BN_zero()/BN_one() to functions and make
BN_zero() always succeed. This will be exposed in the next bump, at which
point we can hopefully also remove the BN_zero_ex() function.
ok tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
BIO_set_callback_ex(3), BIO_get_callback_ex(3), and BIO_callback_fn(3).
Document them, in part by merging from the OpenSSL 1.1.1 branch,
which is still under a free license,
but heavily tweaked by me, in particular:
* mention that BIO_set_callback_arg(3) is misnamed;
* keep our more detailed explanation of the "ret" argument;
* make the list of callback invocations more readable;
* and update the HISTORY section.
|
|
|
|
|
|
|
|
|
|
| |
The overwhelming majority of callers of X509_check_purpose() in our tree
pass a purpose of -1. In this case X509_check_purpose() acts as a wrapper
of x509v3_cache_extensions() which makes sanity checks like non-negativity
of ASN.1 integers or canonicity of RFC 3779 extensions as well as checking
uniqueness of extensions.
from schwarze who beat an initial diff of mine into shape
|
|
|
|
| |
OK tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
jsing@ worries that cycle prevention might increase risk because
software that is not checking return values (and indeed, not checking
is likely common in practice) might silently behave incorrectly
with cycle prevention whereas without, it will likely either crash
right away through infinite recursion or at least hang in an infinite
loop when trying to use the cyclic chain, in both cases making it
likely that the bug will be found and fixed.
Besides, tb@ points out that BIO_set_next(3) ought to behave as
similarly as possible to BIO_push(3), but adding cycle prevention
to BIO_set_next(3) would be even less convincing because that
function does not provide a return value, encouraging users to
expect that it will always succeed. While a safe idiom for checking
the success of BIO_set_next(3) could easily be designed, let's be
realistic: application software would be highly unlikely to pick up
such an idiom.
|
|
|
|
|
| |
ED25519_keypair(3), ED25519_sign(3), and ED25519_verify(3).
Document them.
|
|
|
|
|
|
|
|
|
| |
EVP_PKEY_new_raw_private_key(3), EVP_PKEY_new_raw_public_key(3),
EVP_PKEY_get_raw_private_key(3), and EVP_PKEY_get_raw_public_key(3).
Merge the documentation from the OpenSSL 1.1.1 branch, which is
still under a free license. I tweaked the text somewhat for
conciseness, and argument names for uniformity.
|
|
|
|
| |
Document it.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
and reports failure if a call would result in a cycle.
The algorithm used was originally suggested by jsing@.
Feedback and OK tb@.
|
|
|
|
|
|
|
|
|
| |
The reader may not know what digest BIOs, Base64 BIOs and file BIOs are
and the relevant function names are non-obvious, hence it's not entirely
trivial to find the manuals where they are explained. With these references
a reader should be able to turn the example into actual code.
ok schwarze
|
|
|
|
|
|
| |
If you want to Base64-encode "Hello World\n" using a BIO, you had better
pass "Hello World\n" into it, not something slightly different... While
we're touching this, we might as well write it the way K&R did...
|
| |
|
|
|
|
| |
Feedback and OK tb@.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and next_bio fields of all BIO objects in all affected chains, no
matter what the arguments are.
In particular, if the second argument (the one to be appended) is
not at the beginning of its chain, properly detach the beginning
of its chain before appending.
We have weak indications that this bug might affect real-world code.
For example, in FreeRDP, file libfreerdp/crypto/tls.c, function
bio_rdp_tls_ctrl(), case BIO_C_SET_SSL, BIO_push(3) is definitely
called with a second argument that is *not* at the beginning of its
chain. Admittedly, that code is hard to fathom, but it does appear
to result in a bogus prev_bio pointer without this patch.
The practical impact of this bug in this and other software remains
unknown; the consequences might possibly escalate up to use-after-free
issues if BIO_pop(3) is afterwards called on corrupted BIO objects.
OK tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
invariants of the prev_bio and next_bio fields of all BIO objects
in all involved chains, no matter which arguments this function is
called with.
Both real-world uses of this function (in libssl and freerdp) have
been audited to make sure this makes nothing worse. We believe libssl
behaves correctly before and after the patch (mostly because the second
argument is NULL there), and we believe the code in freerdp behaves
incorrectly before and after the patch, leaving a prev_bio pointer in
place that is becoming bogus, only in a different object before and
after the patch. But after the patch, that bogus pointer is due to a
separate bug in BIO_push(3), which we are planning to fix afterwards.
Joint work with and OK tb@.
|
| |
|
|
|
|
|
| |
BIO_push() and BIO_pop() are misnamed. No need to gently and politely
suggest that their 'names [...] are perhaps a little misleading'.
|
|
|
|
|
|
|
|
|
| |
As schwarze points out, you can pop any BIO in a chain, not just the first
one (bonus points for a great name for this API).
The internal doubly linked was used to fix up the BIO chain bio was part
of when you BIO_pop() a bio that wasn't in the first position, which is
explicitly allowed in our documentation and implied by OpenSSL's.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This flag has been deprecated in OpenSSL 1.1 and has not had an effect
since. This way we can simplify the default check_issued() callback,
which helpfully has its arguments reversed compared to the public API
X509_check_issued().
ok jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Open62541 uses X509_STORE_CTX_get_check_issued(), so provide it along
with X509_STORE_{get,set}_check_issued(). As you would expect, they all
return or take an X509_STORE_CTX_check_issued_fn. The getters aren't const
in OpenSSL 1.1, but they now are in OpenSSL 3...
These will be made available in the next minor bump and will ship in the
stable release of LibreSSL 3.7
Part of OpenSSL commit 1060a50b
See also https://github.com/libressl-portable/portable/issues/748
ok beck jsing
|