| Age | Commit message (Collapse) | Author |
|---|
|
ok tb@
|
|
|
|
i removed the arithmetics -> arithmetic changes, as i felt they
were not clearly correct
ok tb
|
|
Some code roams the wild still calling them.
|
|
Contrary to what bio.h says, it does not *not* retrieve some "IO type",
whatever that is supposed to be, but it is a NOOP, and nothing uses it.
Despite its name, it is unrelated to BIO_f_buffer(3), and please
be careful to not confuse it with BIO_get_buffer_num_lines(3).
|
|
It exposes absurd functionality, and according to codesearch.debian.net,
it is unused except in openssl(1) s_client/s_server -nbio_test.
|
|
feedback and 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).
|
|
|
|
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@.
|
|
|
|
BIO_push() and BIO_pop() are misnamed. No need to gently and politely
suggest that their 'names [...] are perhaps a little misleading'.
|
|
|
|
|
|
X509_verify_cert_error_string() is now thread safe as it no longer returns
a static buffer. Document X509_V_ERR_UNSPECIFIED. Stop asserting that the
X509_V_ERR_CERT_CHAIN_TOO_LONG code is unused, the new verifier can set it.
Add commented versions of various missing error codes in the proper spots
and move X509_V_ERR_UNNESTED_RESOURCE where it belongs.
prompted by claudio
|
|
Merge the documentation from the OpenSSL 1.1.1 branch, which is still
under a free license, tweaked by me.
|
|
Document it.
|
|
Remove many statements that are no longer true after tb@, in July,
massively improved the algorithms used by these functions
and also did some cleanup of the interface. Instead, explain
many aspects that were missing. Also use more descriptive argument
names, drop some redundancy, and improve ordering in various respects.
Feedback and enthusiastic OK from tb@.
|
|
|
|
We don't install this page, but it might possibly still help developers
working on internals of the BN library, so i'm not in a hurry to cvs rm
this file.
|
|
and BN_BITS2 (below RETURN VALUES).
While here, perform major reordering and rewriting
for precision and readability, in particular:
- Avoid misleading wordings like "size of a BIGNUM".
- Drop the trivial example.
- Move the pointers to RSA_size(3) and friends to CAVEATS.
- Stop recommending 8*BN_num_bytes() in this context because it is wrong, too.
|
|
|
|
All other wrappers in the same file that use a temporary array of
degrees size that array dynamically, such that they are able to
handle reducing polynomials of arbitrary lengths. BN_GF2m_mod(3)
was the only one that used a static array of size 6 instead, limiting
it to trinomials and pentanomials and causing it to fail for longer
reducing polynomials.
Make this more uniform and less surprising by using exactly the
same code as in all the other wrappers, such that BN_GF2m_mod(3)
works with reducing polynomials of arbitrary length, too, just like
the others.
Again, tb@ points out this quirk is very unlikely to cause
vulnerabilities in practice because cryptographic applications do
not use longer reducing polynomials.
This patch is not expected to significantly impact performance
because the relevant caller, BN_GF2m_mod_div(3), already uses dynamic
allocation via BN_GF2m_mod_mul(3).
OK tb@
|
|
discussed with schwarze
|
|
ok schwarze
|
|
concerning arithmetic in Galois fields of power-of-2 order
|
