summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/man (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove X509_STORE_CTX_purpose_inherit(3) documentationtb2024-01-121-131/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This abomination of an API will be removed. Remove the hairy details of its internals and make the documentation of X509_STORE_CTX_set_trust(3) and X509_STORE_CTX_set_purpose(3) independent of it. Neither of these two remaining APIs can be recommended. Once set, trust and purpose are sticky. Setting the trust to a different (valid) value will indicate success but leave the value unchanged. I suppose it means the new trust value was successfully ignored. Also, setting the trust to X509_TRUST_DEFAULT can succeed or fail depending on which OpenSSL derivative you use. Setting the purpose will also set the trust (unless it is already set). Setting some purposes may or may not fail depending on the OpenSSL lib. The only way you have a chance of knowing what will be set is by calling only one of these functions directly after X509_STORE_CTX_init(). This isn't really safe either because in some versions the user can override the values stored in a global table by writing directly to it. The actual contributions here are rather minimal. State more explicitly that 0 is invalid (but results in success being returned), document the error values to be accurate across implementations and call out some of the nonsense in a CAVEATS section. Many thanks to schwarze for the very helpful review with lots of input. ok schwarze
* fix previous: key -> parametertb2023-12-291-2/+2
|
* A .Xr to DSA_generate_parameters_ex() was lost accidentallytb2023-12-291-1/+2
|
* Move DSA_generate_parameters.3 to DSA_generate_parameters_ex.3tb2023-12-292-3/+3
|
* Adjust documentation for upcoming DSA_generate_parameters removaltb2023-12-295-70/+17
| | | | | | | This removes any mention of DSA_generate_parameters in the manuals apart from a comment that it is intentionally undocumented and adapts cross references to DSA_generate_parameters_ex. The file itself will be moved in a second step.
* Rename some argument placeholders to be less cryptic,schwarze2023-12-262-55/+58
| | | | | | | | | | | | | | in particular s/inl/in_len/ and s/outl/out_len/ as suggested by tb@. While here, also get rid of the "outm" placeholder that has been around since the file was added to OpenSSL in 2000, replacing it with the usual "out" in the four function prototypes affected; tb@ and myself suspect it was simply a typo followed by copy and paste. Slightly improve variable naming in the examples, too, for clarity and consistency, even though that doesn't turn the examples into good examples. OK tb@
* Close some major gaps in the documentation of EVP_Cipher(3),schwarze2023-12-261-10/+65
| | | | | and describe EVP_CIPHER_CTX_init(3) in a less misleading way. Joint work with and OK tb@.
* Clarify that the ENGINE argument is ignored; OK tb@.schwarze2023-12-251-11/+10
| | | | | While here, also switch the argument placeholder from *impl to *engine as suggested by tb@.
* Remove EVP_PKEY_asn1_add{0,_alias}() documentationtb2023-12-214-78/+14
| | | | | | This API was recently neutered and will be removed in the next major bump. Mark it as intentionally undocumented in EVP_PKEY_asn1_new.3 and remove it from all other manuals.
* Mark some API-to-be-removed as intentionally undocumentedtb2023-12-211-2/+6
|
* ASN1_STRING_TABLE_get.3: grammar: have -> hastb2023-12-161-2/+2
|
* Annotate incorrect value for ub_email_addresstb2023-12-161-1/+6
| | | | | | | | | | | | | | | | | The ub_email_address upper bound, 128, returned for NID_pkcs9_emailAddress, doesn't match the PKCS#9 specification where it is 255. This was adjusted in RFC 5280: The ASN.1 modules in Appendix A are unchanged from RFC 3280, except that ub-emailaddress-length was changed from 128 to 255 in order to align with PKCS #9 [RFC2985]. Nobody seems to have noticed so far, so leave it at an XXX and a BUGS entry for now. It also clearly has the wrong name. Another mystery is why the RFCs suffix some upper bounds with length, but not others. Also, OpenSSL chose to be inconsistent with that, because inconsistency is one of the few things this library is really good at.
* Rename ASN1_STRING_TABLE_add manual to _gettb2023-12-162-3/+3
|
* Remove ASN1_STRING_TABLE_{add,cleanup}() documentationtb2023-12-161-71/+14
| | | | | | | | | | | The unused ASN1_STRING_TABLE extensibility API will be removed in the next major bump and the table itself will become immutable. Lightly adjust the remaining text. In particular, update the RFC reference, stop talking about defaults when nothing can be changed anymore, do not mention useless flags that you will no longer be able to set and move the description of the only remaining flag after the description of ASN1_STRING_TABLE_get(). The file will be renamed in a second step.
* last .Nm should not have a commajsg2023-12-051-3/+3
|
* Some cleanup:schwarze2023-12-011-71/+33
| | | | | | | | | | Remove some lies and some irrelevant historical information about the non_ex variants and waste fewer words deprecating them. Telling people to type longer function names and to pass an ignored NULL argument doesn't really help anything. Also talk less about those ignored ENGINE arguments. OK tb@
* EVP_EncryptInit(3) is among the most important "how to drive" manuals,schwarze2023-12-014-65/+165
| | | | | | | | but it is still excessively long and complicated. To reduce the amount of distractions a bit, split out three deprecated functions into a new manual page EVP_CIPHER_CTX_init(3). No text change. In part suggested by tb@, who agrees with the direction.
* Mark up an occurrence of ENGINEtb2023-11-191-2/+3
|
* ENGINE can no longer have ex_data attached to ittb2023-11-191-3/+3
|
* Remove musings how ENGINE may or may not screw everything up.tb2023-11-191-23/+2
|
* Remove ENGINE mention in RSA_new()tb2023-11-191-14/+6
|
* OPENSSL_config() no longer calls ENGINE_load_builtin_engines()tb2023-11-191-5/+4
|
* ENGINE_add_conf_module() no longer existstb2023-11-191-8/+2
|
* Remove ENGINE Xr that I left behindtb2023-11-191-2/+1
|
* zap stray commatb2023-11-191-2/+2
|
* Also mention ENGINE_{cleanup,{ctrl_cmd{,_string}()tb2023-11-191-3/+29
|
* Missing periodtb2023-11-191-2/+2
|
* fix grammartb2023-11-191-2/+2
|
* Remove remaining ENGINE manualstb2023-11-1911-1988/+1
| | | | They document functionality that no longer exists.
* Strip mention of ENGINE out of *_set_method.3tb2023-11-193-98/+26
|
* Strip out mentions of ENGINE_load_builtin_engines()tb2023-11-191-7/+4
| | | | | There's probably more that needs to be updated here, but that can be done another day.
* ex data for ENGINEs is no longer a thingtb2023-11-191-9/+2
|
* Remove section explaining how great and flexible ENGINE is andtb2023-11-191-28/+2
| | | | remove two Xr to ENGINE manuals.
* Remove obsolete engine configuration sectiontb2023-11-191-106/+2
|
* Document the remaining ENGINE stubs in a single manualtb2023-11-191-146/+103
|
* EVP_PKEY_encrypt() simplify exampletb2023-11-191-6/+4
| | | | In particular, do not use an uninitialized engine, simply pass NULL.
* Mention which functions are implemented as macros in the few casesschwarze2023-11-1613-34/+76
| | | | where that information was missing.
* drop some duplicate statements about macrosschwarze2023-11-164-23/+10
|
* fix wrong macroschwarze2023-11-161-3/+3
|
* delete lots of stuff that no longer existsschwarze2023-11-161-300/+17
|
* fix typo: exdata -> ex_dataschwarze2023-11-161-4/+4
|
* Minimal fix to unbreak OPENSSL_{gmtime,timegm}(3)tb2023-11-161-15/+18
| | | | | | I was told not to look since it will magically get fixed. Fine. I'd still have expected a minimal amount of care so that the manpage isn't totally dysfunctional and missing text in the right places. Sigh.
* Prepare to expose OPENSSL_gmtime and OPENSSL_timegm as publicbeck2023-11-131-2/+42
| | | | | | | | | | | This matches when BoringSSL has done, and allows for getting rid of the dependency on system timegm() and gmtime() in libtls. which will make life easier for portable, and remove our dependency on the potentially very slow system versions. ok tb@ - tb will handle the minor bump bits and expose on the next minor bump CVS :----------------------------------------------------------------------
* Remove mention of alg_section. This never worked in LibreSSL.tb2023-10-211-3/+2
|
* style tweak: avoid double conjunction to make it read betterschwarze2023-10-211-4/+4
| | | | OK tb@
* Rename the modulus from n into mtb2023-10-191-9/+12
| | | | | This matches what other pages use. Also rewrite the definition of the modular inverse to be less ugly.
* Tweak previous by using the argument name, not its typetb2023-10-131-2/+2
|
* Improve the description of X509_ALGOR_dup(3)tb2023-10-131-5/+11
| | | | | The old description was vague, but strictly speaking a lie, so make it more precise and turn the lie into a truth.
* I forgot that we now have ASN1_INTEGER_set_uint64()tb2023-10-111-13/+6
|
* Be more precise about X509_ALGOR_get0()tb2023-10-111-11/+26
|