summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/man (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove X509_OBJECT_free_contets() docstb2025-03-081-20/+3
|
* Remove X509_OBJECT_up_ref_count() documentationtb2025-03-081-23/+2
|
* Remove EC_PIONT_{get,set}_Jprojective_coordinates_GFp docstb2025-03-081-53/+1
|
* Remove EC_POINTs_{make_affine,mul}() docstb2025-03-081-67/+2
|
* Remove EC_GROUP_{,have_}precompute_mult() docstb2025-03-081-31/+4
|
* Remove EC_GROUP_method_of() docstb2025-03-081-20/+1
|
* Remove EC_GFp_* and EC_METHOD_get_field_type docstb2025-03-087-156/+12
|
* X509_NAME_print() also fails to indenttb2025-01-081-5/+6
|
* X509_NAME_print: remove lie about multiple lines being usedtb2025-01-071-4/+2
| | | | | | | | | | | | | OpenSSL commit 92ada7cc (2007) removed some dead code with flawed logic attempting to print multiple lines if the line exceeded 80 characters. Said flawed logic was there since the start of the git history importing SSLeay 0.8.1b in 1998 and never worked. Rumor has it that it did work prior to that. Be that as it may, it's just wrongly documented since Henson added the docs in commit 0711be16 (2002). Prompted by OpenSSL issue #18004 by davidben https://github.com/quictls/quictls/pull/168 https://github.com/quictls/quictls/issues/75
* Remove most of the RSA_FLAG_SIGN_VER documentationtb2025-01-052-33/+6
| | | | ok jsing kn
* NID_sxnet and NID_proxyCertInfo are no longer supportedtb2024-12-311-7/+2
| | | | The code supporting it was removed in April 2023.
* Prefer the constants EVP_CTRL_AEAD_* over EVP_CTRL_CCM_* and EVP_CTRL_GCM_*schwarze2024-12-292-12/+110
| | | | | | | | | | | | | | because that's what OpenSSL 1.1 suggests. Even though that "unification" doesn't really simplify anything but is more akin to repainting the bikeshed, at least it doesn't cause any additional harm, so keeping recommendations consistent may reduce the risk of code breaking in the future. Provide an example of decryption with AES-CCM in addition to the example of encryption already in place, because there are a number of subtle and non-obvious differences that users have to pay attention to. Both ideas originally suggested by tb@.
* Document X509V3_ADD_OP_MASK and clarify the description of the flags argument.schwarze2024-12-281-5/+31
| | | | | While here, also add a (c) line for tb@ because he added Copyright-worthy amounts of text to this page during the last two years.
* Document X509_supported_extension(3).schwarze2024-12-281-6/+28
| | | | | | The sentence about X509_EXTENSION_get_critical(3) in the DESCRIPTION contained broken grammar or at least broken punctuation, and more importantly, redundant and misplaced information. While he, shorten it.
* Document X509V3_EXT_print_fp(3).schwarze2024-12-281-28/+67
| | | | | Sort the list of decoding functions alphabetically by extension type. List the printing functions that are already documented.
* new manual page a2i_ipadd(3) written from scratchschwarze2024-12-276-11/+157
|
* new manual page v2i_ASN1_BIT_STRING(3) written from scratchschwarze2024-12-246-11/+141
|
* ealier -> earlierjsg2024-12-231-4/+4
|
* new manual page X509V3_parse_list(3) written from scratchschwarze2024-12-232-1/+102
|
* Tweak previous wording a bit to avoid suggesting all built-in nidstb2024-12-231-2/+2
| | | | | | correspond to an extension method. ok schwarze
* more precision below CAVEATSschwarze2024-12-231-3/+5
|
* Make the description of i2s_ASN1_ENUMERATED_TABLE(3) more precise,schwarze2024-12-231-9/+12
| | | | | fix the name of its last parameter in the SYNOPSIS to match the DESCRIPTION, and let the .Dt argument match the file name.
* mark six #define'd constants as intentionally undocumentedschwarze2024-12-221-2/+7
|
* Add an EXAMPLES section.schwarze2024-12-211-2/+129
| | | | | | | | | | | | | | | | I admit this is unusually long for a manual page. But that's not my fault as a documentation author. An example in a manual page ought to be minimal to show what needs to be demonstrated, and this example is minimal in that sense. Making it shorter without loosing important aspects does not seem possible. When an API is poorly designed, one of the consequences is that that documentation becomes harder to understand and often longer - in this case to the point of becoming outright intimidating. If people dislike that, they should design better APIs in the first place rather than blasting the poor manual page for being too long or too complicated. OK tb@
* Move the horrific EVP_aes_128_ccm(3) API out of the important,schwarze2024-12-204-75/+357
| | | | | | | | | | | | algorithm-independent EVP_EncryptInit(3) manual as another step in making the latter leaner and more palatable. As a side benefit, the new EVP_aes_128_ccm(3) manual page may provide a better fighting chance to programmers who see themselves forced to support CCM for whatever reason. It documents the mandatory, but so far undocumented EVP_CTRL_CCM_GET_TAG control command and makes the description of the three EVP_CTRL_CCM_SET_* control commands and the numerous related quirks more precise.
* kength -> lengthjsg2024-12-181-3/+3
|
* New manual page EVP_aes_128_gcm(3).schwarze2024-12-174-75/+260
| | | | | | | | | | | | The main benefit is moving the cumbersome and error-prone method of using EVP_EncryptInit(3) for AES-GCM out of the important, but obese manual page EVP_EncryptInit(3), and to create a logical place for pointing readers to the safer and more flexible EVP_AEAD_CTX_init(3). As a side benefit, document three control commands that were so far undocumented and make the description of three others more precise. Feedback and OK tb@.
* Improve a rather misleading sentence about EVP_PKEY_new_mac_key(3).schwarze2024-12-101-4/+8
| | | | | | | It does *not* "work in the same way" as EVP_PKEY_new_raw_private_key(3) but merely arrives at the same end result after doing lots of cumbersome and unnecessary work - and on top of that, it only works for EVP_PKEY_HMAC.
* Add a paragraph about HMAC because that algorithm also involvesschwarze2024-12-101-3/+15
| | | | | | | | parameters that can be controlled with EVP_PKEY_CTX_ctrl(3). But rather than providing a detailed despription, instead point to what application programs should use instead and explain why using the control constant directly would be a particularly bad idea in this case.
* insert a forgotten .Dv macroschwarze2024-12-091-3/+3
|
* Mark the constants EVP_PK_*, EVP_PKS_*, and EVP_PKT_* as intentionallyschwarze2024-12-091-2/+7
| | | | | undocumented because they are only used by the function X509_certificate_type() which is deprecated and will eventually be deleted.
* Move the algorithm-specific functions EVP_rc2_*(3) out of EVP_EncryptInit(3)schwarze2024-12-084-55/+214
| | | | | | | | | and document them properly in their own manual page, including the control commands EVP_CTRL_SET_RC2_KEY_BITS and EVP_CTRL_GET_RC2_KEY_BITS that were so far undocumented. Arguably, the main benefit is another small step making the important, but still obese EVP_EncryptInit(3) manual page more palatable.
* Document the low-level rc2.h API.schwarze2024-12-072-2/+198
| | | | | Not that this would be particularly important, but i had to look at the code anyway while completing the EVP documentation.
* Adjust the return type and value of EVP_MD_CTX_init(3)schwarze2024-12-062-7/+12
| | | | | and EVP_CIPHER_CTX_init(3) after tb@ changed these to OpenSSL 1.1 semantics in evp.h rev. 1.124 on March 2 this year.
* Delete the manual pages EVP_PKEY_meth_new(3) and EVP_PKEY_meth_get0_info(3)schwarze2024-12-0618-776/+60
| | | | | | | | because tb@ deleted almost all functions documented there from the API in evp.h 1.127 on March 2 this year, but move the functions EVP_PKEY_CTX_set_data(3) and EVP_PKEY_CTX_get_data(3) that we still support to EVP_PKEY_keygen(3), because that page already documents EVP_PKEY_CTX_set_app_data(3) and EVP_PKEY_CTX_get_app_data(3).
* Delete the manual page EVP_PKEY_check(3).schwarze2024-12-065-158/+5
| | | | | All three functions documented in this page were deleted from the API by tb@ in evp.h rev. 1.136 on August 31 this year.
* Delete the manual page EVP_PKEY_asn1_new(3).schwarze2024-12-0614-566/+30
| | | | | All the functions documented in this page were deleted from the API by tb@ in evp.h rev. 1.126 on March 2 this year.
* Explain what "EVP" is supposed to mean.schwarze2024-12-061-2/+16
| | | | | | It's so non-obvious that even i had to do some research to find out. Source: The file "doc/ssleay.doc" from SSLeay 0.8.1b, see for example OpenSSL commit d02b48c6 on Dec 21, 1998.
* document the #define'd constant PKCS5_SALT_LENschwarze2024-12-051-4/+6
|
* drop comments asking for documentation of three ASN1_PKEY_CTRL_CMS_*schwarze2024-12-051-5/+2
| | | | | constants after these have been marked as intentionally undocumented; they are internal to the library and unused in the wild
* Meant to split the sentence in twotb2024-11-301-3/+3
|
* Be a bit more precise on the error conditions of CMS_get1_{certs,crls}()tb2024-11-301-3/+4
|
* Explain how to free the stack returned by CMS_get1_{certs,crls}()tb2024-11-301-2/+9
| | | | with job
* Provide an example of signing with HMAC-SHA256 or Ed25519schwarze2024-11-291-3/+67
| | | | | | because that makes it easier to see the big picture of how EVP_PKEY_new_raw_private_key(3) is supposed to be used. Feedback and OK tb@.
* Fix some inaccuracies and gaps in the paragraph i wrote about CMACschwarze2024-11-241-18/+47
| | | | | | | | | such that it becomes intelligible but not too long or prominent. In particular, don't talk about EVP_PKEY_CTX_new(3), don't forget to mention EVP_PKEY_keygen(3), mention EVP_PKEY_OP_KEYGEN, and mention how to proceed once you have the desired EVP_PKEY object in hand. Substantial feedback and OK tb@.
* Use a better curve and a better hash for the ECDSA_do_sign() exampletb2024-11-151-9/+9
| | | | (Many examples in this directory are really bad. This is no exception.)
* Link the new manual page EVP_PKEY_new_CMAC_key(3) to the buildschwarze2024-11-122-29/+5
| | | | | and purge the superseded information from the algorithm-independent page EVP_PKEY_new(3).
* Document EVP_PKEY_new_CMAC_key(3) in sufficient detail such that readersschwarze2024-11-121-0/+159
| | | | | | | | | | | | | | | | | | | | | stand a chance of using the API correctly. Admittedly, having so much text below EXAMPLES is somewhat unusual. While all that information is required to use the function correctly, strictly speaking, it is not part of the specification of what EVP_PKEY_new_CMAC_key(3) does, so it woundn't really belong in the DESCRIPTION. Now, designing an API function in such a way that using it correctly requires lots of information about *other* functions and such that all that additional information does not belong into the manual pages of those other functions (both because that would cause distractions in various other manual pages and because it would scatter required information around lots of different pages) is certainly not stellar API design. But we can't help that because these APIs were all originally designed by OpenSSL. Significant feedback and OK tb@.
* Fix a brainfart that happened to me in 2020:schwarze2024-11-121-9/+7
| | | | | | | | | | It is impossible to use EVP_DigestInit_ex(3) for CMAC. Besides, EVP_PKEY_CTX_new_id(3) does not produce an EVP_MD_CTX object. Instead, mention the easiest way to actually get the job done using EVP_PKEY_new_CMAC_key(3) and EVP_DigestSignInit(3). OK tb@
* Mention the key lengths of some encryption algorithms.schwarze2024-11-094-21/+47
| | | | | | | | This is relevant because EVP_EncryptInit(3) takes a "key" argument, and users need to consider the size of that argument. While here, also mention whether ciphers are stream ciphers or block ciphers and what the block size is.
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-08 11:47:13 +0000