summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/man (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* succcess -> successjsg2022-12-281-3/+3
|
* spelling fixes; from paul tagliamontejmc2022-12-263-9/+9
| | | | | | | i removed the arithmetics -> arithmetic changes, as i felt they were not clearly correct ok tb
* Document the deprecated wrappers BIO_set_app_data(3) and BIO_get_app_data(3).schwarze2022-12-231-5/+36
| | | | Some code roams the wild still calling them.
* Mark BIO_buffer_get_num_lines(3) as intentionally undocumented.schwarze2022-12-231-2/+5
| | | | | | | 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).
* Mark BIO_f_nbio_test(3) as intentionally undocumented.schwarze2022-12-231-2/+5
| | | | | It exposes absurd functionality, and according to codesearch.debian.net, it is unused except in openssl(1) s_client/s_server -nbio_test.
* new manual page BIO_s_datagram(3);schwarze2022-12-233-3/+577
| | | | feedback and OK tb@
* new manual page BIO_accept(3)schwarze2022-12-223-3/+387
|
* Mark BIO_s_log(3) as intentionally undocumented.schwarze2022-12-221-3/+4
| | | | | | | | 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!
* Mark BIO_nread0(3), BIO_nread(3), BIO_nwrite0(3), and BIO_nwrite(3)schwarze2022-12-211-2/+8
| | | | | | | | | | | 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.
* Mark BIO_dump_cb(3) and BIO_dump_indent_cb(3) as intentionally undocumented.schwarze2022-12-201-2/+5
| | | | | | 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.
* document BIO_fd_non_fatal_error(3) and BIO_fd_should_retry(3)schwarze2022-12-201-8/+76
|
* document BIO_copy_next_retry(3)schwarze2022-12-191-5/+34
|
* document BIO_FLAGS_MEM_RDONLYschwarze2022-12-181-2/+17
|
* document BIO_set_retry_read(3), BIO_set_retry_write(3),schwarze2022-12-181-5/+95
| | | | | BIO_set_retry_special(3), BIO_clear_retry_flags(3), BIO_get_retry_flags(3), and the BIO_FLAGS_* constants
* new manual page BIO_dup_chain(3)schwarze2022-12-189-19/+206
|
* correct the prototypes of BIO_get_conn_ip(3) and BIO_get_conn_int_port(3);schwarze2022-12-181-5/+3
| | | | | from Richard Levitte via OpenSSL commit 0e474b8b in the 1.1.1 branch, which is still under a freee license
* document BIO_number_read(3) and BIO_number_written(3)schwarze2022-12-181-5/+67
|
* Merge documentation of UI_null() from OpenSSL 1.1tb2022-12-171-5/+21
| | | | | | jsing doesn't like it, but it's better than nothing. ok jsing
* Document BIO_set_flags(3), BIO_clear_flags(3), BIO_test_flags(3),schwarze2022-12-171-4/+88
| | | | and BIO_get_flags(3).
* X509_check_purpose.3: incorporate feedback from jsingtb2022-12-171-5/+5
|
* In bio.h rev. 1.54, jsing@ and tb@ provided BIO_callback_fn_ex(3),schwarze2022-12-161-77/+192
| | | | | | | | | | | 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.
* Document extension caching of X509_check_purpose()tb2022-12-161-23/+43
| | | | | | | | | | 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
* add a CAVEATS section warning the user to not create cycles;schwarze2022-12-161-1/+34
| | | | OK tb@
* Revert BIO_push(3) cycle prevention (bio_lib.c rev. 1.42).schwarze2022-12-161-32/+6
| | | | | | | | | | | | | | | | | | | 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.
* In curve25519.h rev. 1.4 to 1.7, tb@ and jsing@ providedschwarze2022-12-151-11/+121
| | | | | ED25519_keypair(3), ED25519_sign(3), and ED25519_verify(3). Document them.
* In evp.h rev. 1.109 and 1.112, jsing@ and tb@ providedschwarze2022-12-141-61/+154
| | | | | | | | | 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.
* In asn1.h rev. 1.71 and 1.72, jsing@ and tb@ provided ASN1_buf_print(3).schwarze2022-12-144-5/+78
| | | | Document it.
* Fix copy-paste error that left a paragraph ending in a commatb2022-12-081-3/+3
|
* Improve the implementation of BIO_push(3) such that it changes nothingschwarze2022-12-071-5/+32
| | | | | | and reports failure if a call would result in a cycle. The algorithm used was originally suggested by jsing@. Feedback and OK tb@.
* Add references to the BIO_{push,pop}(3) exampletb2022-12-071-3/+8
| | | | | | | | | 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
* Fix example stringtb2022-12-071-4/+4
| | | | | | 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...
* Zap extra spacetb2022-12-061-3/+3
|
* Major rewrite for accuracy and clarity, and document BIO_set_next(3).schwarze2022-12-061-37/+148
| | | | Feedback and OK tb@.
* arithmethic -> arithmeticjsg2022-12-061-3/+3
|
* Drop 'perhaps a little', plus grammar and spelling nitstb2022-12-021-5/+5
| | | | | BIO_push() and BIO_pop() are misnamed. No need to gently and politely suggest that their 'names [...] are perhaps a little misleading'.
* Mark the X509_V_FLAG_CB_ISSUER_CHECK flag as deprecatedtb2022-12-011-11/+5
|
* Add missing markup to comments and to RFC 3779 errortb2022-11-291-10/+12
|
* First pass at updating verifier error docstb2022-11-291-13/+41
| | | | | | | | | | 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
* In bio.h rev. 1.50 and rev. 1.51, tb@ provided BIO_set_retry_reason(3).schwarze2022-11-271-4/+20
| | | | | Merge the documentation from the OpenSSL 1.1.1 branch, which is still under a free license, tweaked by me.
* In bio.h rev. 1.46/1.47 (Oct/Nov 2021), tb@ provided BIO_get_init(3).schwarze2022-11-251-5/+23
| | | | Document it.
* Major overhaul.schwarze2022-11-241-210/+216
| | | | | | | | | | 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@.
* mention what BN_ULONG isschwarze2022-11-223-8/+33
|
* Remove the lie that BN_ULONG might be 16 bits wide.schwarze2022-11-221-9/+11
| | | | | | 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.
* Better document BN_ULONG (in the DESCRIPTION near BN_num_bits_word(3))schwarze2022-11-221-40/+84
| | | | | | | | | | | 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.
* document BN_nist_mod_521(3) and their four siblingsschwarze2022-11-213-3/+118
|
* Fix a surprising quirk in BN_GF2m_mod(3).schwarze2022-11-201-11/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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@
* group -> fieldtb2022-11-181-5/+5
| | | | discussed with schwarze
* polynominal -> polynomialtb2022-11-181-18/+18
| | | | ok schwarze
* new manual page BN_GF2m_add(3)schwarze2022-11-183-3/+527
| | | | concerning arithmetic in Galois fields of power-of-2 order
* mark BN_X931_derive_prime_ex, BN_X931_generate_prime_ex,schwarze2022-11-161-2/+8
| | | | | and BN_X931_generate_Xpq as intentionally undocumented because they are unused outside OpenSSL/LibreSSL and deprecated in OpenSSL 3.0
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-14 21:40:03 +0000