summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/man (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Document X509_V_ERR_UNNESTED_RESOURCE. Previous version looked goodtb2022-01-241-2/+9
| | | | to claudio
* Document the bizarre fact that {CMS,PCKS7}_get0_signers() needs sometb2022-01-192-4/+12
| | | | | | | | | | | freeing of what they return despite being get0 functions: the stack of X509s that they return must be freed with sk_X509_free(). The get0 thus probably refers to the individual certs, but not to the stack itself. The libcrypto and libssl APIs never cease to amaze with new traps. ok inoguchi
* spellingjsg2022-01-1510-33/+33
| | | | ok tb@
* Add back an accidentally dropped .Pptb2022-01-151-1/+2
|
* Update for HMAC_CTX_{init,cleanup} hand HMAC_cleanup removaltb2022-01-151-50/+2
|
* Stop documenting clone digests.tb2022-01-153-47/+7
|
* ASN1_{,F,T}BOOLEAN_it and the encoding and decoding API will movetb2022-01-125-147/+7
| | | | | | to internal only soon. Stop documenting them. ok inoguchi jsing
* Document EVP_AEAD_CTX_{new,free}() and adjust example code.tb2022-01-101-6/+45
| | | | looks good to jsing
* fix strange indentation in code exampletb2022-01-021-3/+3
|
* identfier -> identifierjsg2022-01-012-6/+6
|
* excpetions -> exceptionsjsg2021-12-311-3/+3
|
* deafult -> defaultjsg2021-12-311-3/+3
|
* document BN_MONT_CTX_set_locked(3)schwarze2021-12-211-5/+72
|
* document BN_mod_add_quick(3), BN_mod_sub_quick(3), BN_mod_lshift(3),schwarze2021-12-201-3/+115
| | | | BN_mod_lshift_quick(3), BN_mod_lshift1(3), and BN_mod_lshift1_quick(3)
* document BN_consttime_swap(3); this will probably require more work,schwarze2021-12-191-7/+80
| | | | but what i have so far is already better than nothing
* document BN_uadd(3) and BN_usub(3)schwarze2021-12-191-7/+78
|
* document BN_zero_ex(3)schwarze2021-12-191-6/+38
|
* Document BN_abs_is_word(3).schwarze2021-12-181-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | While here, add the missing "const" qualifier to the second parameter of BN_is_word(3) - even though i doubt that marking an integral type parameter as "const" serves any significant purpose... Note that the OpenSSL documentation for this function that Billy Brumley committed on August 4, 2021 is actually wrong. Essentially, it says "BN_abs_is_word() test[s] if a equals ... |w|." Now pray tell me, what exactly is the point of taking the absolute value of an unsigned integer number? To compensate for the obvious absurdity of his patch, Billy made a point of getting *three* OKs from rather notable people: Pauli Dale, Nicola Tuveri, and Dmitry Belyavskiy. I believe this is a striking example of the cavalier attitude some projects put on display when it comes to documentation, and also a striking example of how bad documentation can occasionally be worse than no documentation at all, because the OpenSSL manual page will now thoroughly confuse anyone reading it. SCNR pointing out this (hopefully unintentional) hilarity - or is this an attempt at trolling the readers of their documentation? If it is, they certainly got me.
* add the missing .Nm BN_get_rfc3526_prime_1536,schwarze2021-12-181-2/+3
| | | | fixing a minibug found with check_complete.pl
* new manual page OBJ_add_sigid(3)schwarze2021-12-189-19/+155
|
* new manual page OBJ_NAME_add(3)schwarze2021-12-175-9/+363
|
* mention lh_strhash(3) in the NAME, SYNOPSIS, and HISTORY sections;schwarze2021-12-171-10/+20
| | | | while here, repair a typo in the lh_retrieve(3) synopsis
* document obj_cleanup_defer(3) and check_defer(3)schwarze2021-12-162-8/+72
|
* document OBJ_new_nid(3), OBJ_add_object(3), and OBJ_create_objects(3);schwarze2021-12-151-9/+91
| | | | mark OBJ_create_and_add_object() as intentionally undocumented
* Move OBJ_create(3) into its own manual pageschwarze2021-12-155-63/+157
| | | | | because OBJ_nid2obj(3) is already long and more functions related to OBJ_create(3) have to be documented.
* Document i2c_ASN1_INTEGER(3).schwarze2021-12-151-7/+46
| | | | | | | | | | | | | While it was probably a mistake that steve@ made some i2c_*() and c2i_*() functions public back in 2000 and while we would like to delete them from the API, it may not be possible to delete this particular function because in contrast to the others (which are already marked as intentionally undocumented), this one is used by various real-world software, so for now, explain what it does, just in case people find it in existing code. While here, use the familiar term "byte" that we generally use throughout all our manual pages, even though the ASN.1 standard uses the term "octet" instead, which is more precise only in theory.
* forgotten .Dv macros in -column listsschwarze2021-12-142-19/+19
|
* add roff(7) comments listing some M_ASN1_* aliasesschwarze2021-12-143-6/+11
| | | | that are intentionally undocumented
* document the very quirky behaviour of the SMIME_OLDMIME flagschwarze2021-12-141-3/+39
|
* new manual page SMIME_text(3)schwarze2021-12-144-5/+65
|
* new manual page SMIME_read_ASN1(3)schwarze2021-12-144-8/+134
| | | | using parts of the text from SMIME_read_CMS(3) and SMIME_read_PKCS7(3)
* new manual page PEM_write_bio_ASN1_stream(3);schwarze2021-12-135-6/+100
| | | | | certainly not perfect, but arguably better than the even terser PEM_write_bio_CMS_stream(3) and PEM_write_bio_PKCS7_stream(3)
* new manual page SMIME_write_ASN1(3);schwarze2021-12-135-9/+179
| | | | still vague in various respects, but it's a start
* new manual pages i2d_ASN1_bio_stream(3) and SMIME_crlf_copy(3)schwarze2021-12-136-8/+203
|
* document the ub_* constantsschwarze2021-12-121-2/+22
|
* typoschwarze2021-12-121-2/+2
|
* New manual page providing a rudimentary description of BIO_new_NDEF(3).schwarze2021-12-124-5/+127
| | | | | | | The API surrounding this is so complicated and streaming is so rarely used in practice that describing this in more detail is not a priority right now. The documentation of the wrapper BIO_new_CMS(3) is also rather vague, and BIO_new_PKCS7() isn't described at all so far.
* document STABLE_NO_MASK and STABLE_FLAGS_MALLOC,schwarze2021-12-111-13/+32
| | | | | mention which argument values can be used to not change the respective fields, and tweak a few additional wordings
* two more "the the" fixes;jmc2021-12-111-3/+3
|
* explain how X509_NAME_ENTRY_set_data(3) uses MBSTRING_FLAGschwarze2021-12-101-5/+20
|
* document the following constants:schwarze2021-12-102-4/+28
| | | | | B_ASN1_DIRECTORYSTRING, B_ASN1_PRINTABLE, B_ASN1_DISPLAYTEXT, B_ASN1_TIME, DIRSTRING_TYPE, PKCS9STRING_TYPE
* document V_ASN1_SEQUENCE and V_ASN1_SETschwarze2021-12-091-4/+9
|
* document V_ASN1_BOOLEANschwarze2021-12-091-2/+4
|
* improve the documentation of V_ASN1_APP_CHOOSEschwarze2021-12-092-6/+15
|
* Mention V_ASN1_PRIMITIVE_TAG and V_ASN1_EOC.schwarze2021-12-091-5/+14
| | | | | Seeing the symbolic names in addition to the magic numbers makes it esier to understand the text.
* add the missing STANDARDS sectionschwarze2021-12-091-2/+8
|
* Document V_ASN1_ANY.schwarze2021-12-091-12/+15
| | | | | | While here, tweak some wordings a bit to make it less likely that readers confuse the type held by an ASN1_TYPE object with the type of the ASN1_TYPE object itself, which is always V_ASN1_ANY.
* document V_ASN1_NEGschwarze2021-12-091-3/+10
|
* document V_ASN1_OBJECTschwarze2021-12-091-2/+6
|
* document V_ASN1_NULLschwarze2021-12-091-2/+6
|