summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/man (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* expose the documentation of X509_STORE_CTX_verify_fn(3)schwarze2022-11-162-42/+26
| | | | | and X509_STORE_set_verify(3) and document X509_STORE_get_verify(3) which tb@ all provided with x509_vfy.h revisions 1.48 and 1.49
* document X509_STORE_CTX_verify_cb(3) and X509_STORE_get_verify_cb(3)schwarze2022-11-162-13/+40
| | | | which tb@ provided with x509_vfy.h revisions 1.48 and 1.49
* Mark BN_mod_exp2_mont() as intentionally undocumented.schwarze2022-11-161-3/+4
| | | | | | | | | | | It appears to be intended for internal use by DSA_do_verify(3) and using codesearch.debian.net, i found nothing outside OpenSSL/LibreSSL using it. In April 2018, jsing@ questioned whether the five related functions BN_mod_exp_mont() and friends should even be exposed by <openssl/bn.h>, so we decided to not document them. Now tb@ agrees that there is no reason to document BN_mod_exp2_mont() as long as we don't want to document BN_mod_exp_mont().
* document BN_mod_sqrt(3)schwarze2022-11-154-5/+119
|
* document BN_kronecker(3)schwarze2022-11-143-3/+61
|
* document BN_reciprocal(3)schwarze2022-11-141-10/+55
|
* Various improvements; joint work with beck@:schwarze2022-11-131-64/+72
| | | | | | | | | | | 1. Explain up front what "ASN1_TIME" is (suggested by beck@, wording by me). 2. For opaque structs, use the generic term "object", like we already do it in many other LibreSSL manual pages. 3. Drop some redundant phrases. 4. Improve the EXAMPLES section (by beck@, with fixes by me). 6. Add a STANDARDS section. ...and some other minor polishing. OK beck@
* In asn1.h rev. 1.65, beck@ provided ASN1_TIME_set_string_X509(3),schwarze2022-11-101-11/+139
| | | | | | | | | ASN1_TIME_normalize(3), ASN1_TIME_to_tm(3), ASN1_TIME_cmp_time_t(3), and ASN1_TIME_compare(3). Merge documentation from the OpenSSL 1.1.1 branch, which is still under a free license, with tweaks by me in several respects to match our implementation, and also using some feedback from beck@. OK beck@.
* Document that OPENSSL_free() is required in some circumstancestb2022-11-061-2/+6
| | | | | | | | | | BoringSSL uses the common trick of storing malloc metadata in a prefix and then returning a pointer with an offset. Therefore callers must not call free() but OPENSSL_free(). Reported by dropk1ck via tobhe ok beck jsing
* zap extra .Pptb2022-09-121-2/+1
|
* Stop documenting i2c_ASN1_INTEGER.tb2022-09-122-48/+4
| | | | | This is no longer public API. Also remove some comments about i2c and c2i functions being intentionally undocumented since they are no longer public.
* fix repeated wordsjsg2022-09-112-6/+6
|
* carrier return character -> carriage return characterjsg2022-09-101-2/+2
| | | | ok jmc@ miod@
* fix repeated wordsjsg2022-09-104-12/+12
| | | | ok ok miod@ ack ack jmc@
* fix repeated wordsjsg2022-09-101-3/+3
| | | | ok miod@ jmc@
* Remove more mkerr.pl remnants, missed in previouskn2022-09-061-54/+3
| | | | | Noticed by jsg Feedback OK jsg
* Remove most mentions of contexts on the stack.tb2022-08-312-23/+4
|
* Adjust signatures of BIO_ctrl functionstb2022-08-181-13/+10
| | | | | | | | | | | | | | | In bio.h r1.54, the signature of BIO_callback_ctrl() was changed from bio_info_cb to BIO_info_cb. Adjust manual to reflect this change. At the moment, bio_info_cb and BIO_info_cb are still distinct types with our BIO_info_cb matching OpenSSL's definition. Historically, bio_info_cb had a different type, but that leads to issues with casting function pointers. The ecosystem has moved on to embrace the new type and several ports confuse the two types because OpenSSL decided to "solve" the issues with "typedef BIO_info_cb bio_info_cb; /* backward compatibilty */". We will align with this in the next bump. ok jsing
* Zap trailing whitespacetb2022-07-141-4/+4
|
* add a few .Xr links to new manual pagesschwarze2022-07-1311-24/+36
|
* In dsa.h rev. 1.34 (14 Jan 2022), tb@ provided DSA_bits(3).schwarze2022-07-131-10/+51
| | | | | | | Document it from scratch. While here, merge a few details from the OpenSSL 1.1.1 branch, which is still under a free license, into the documentation of DSA_size(3).
* In x509_vfy.h rev. 1.54, tb@ provided X509_VERIFY_PARAM_get_time(3)schwarze2022-07-131-3/+44
| | | | | | and X509_VERIFY_PARAM_set_auth_level(3). Document them. For the latter, i included a few sentences from the OpenSSL 1.1.1 branch, which is still under a free license.
* link three new manual pages to the buildschwarze2022-07-131-1/+4
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-23 13:14:37 +0000