summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/man (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove CMAC_resume()tb2024-03-021-24/+2
| | | | | | | | | While it is a neat design detail of CMAC that you can resume it after having finalized it, nothing uses this functionality and it adds some gross things such as retaining intermediate secrets in the CMAC ctx. Once this is gone, we can simplify the CMAC code a bit. ok jsing
* Remove BIO_{sn,v,vsn}printf(3)tb2024-03-021-55/+4
| | | | | | | Unsued printing functionality. If something should need this we can readily add it back. ok jsing
* Update ASN1_TIME_set(3)tb2024-02-181-5/+44
| | | | | | | Document OPENSSL_{posix_to_tm,tm_to_posix}() and fix the documentation of OPENSSL_{gmtime,timegm}(). ok jsing
* Make it explicit that the EC_KEY setters don't check thingstb2024-02-161-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While EC_POINT_set_affine_coordinates() checks that the resulting point is on the elliptic curve, this is only necessary, but not sufficient, to ensure that the point can serve as a valid public key. For example, this does not check for normalized coordinates or exclude that it is zero (the point at infinity). Such checks, and more, are performed by the similarly named EC_KEY_set_public_key_affine_coordinates(). This kind of makes sense from the mathematical standpoint as an elliptic curve point isn't a priori a public key, even if you are not going to use libcrypto for actual mathematics (or anything really) unless you like pain. In a cryptographic library such differences are more of a hazard than a help. This is exacerbated by the fact that EC_KEY_set_public_key() does almost no checking (it only checks that the point's EC_POINT method matches the one of group set of the EC_KEY, which is far from enough). The API expects that you call EC_KEY_check_key() on your own. This is kind of confusing since EC_KEY_set_public_key_affine_coordinates() does that for you. Unfortunately, adding sanity checks to EC_KEY_set_public_key() isn't easy since it's going to penalize those who already check. Caching the result of a check is dangerous and fragile if there are a million ways of fiddling with an EC_KEY. While the elliptic curve code is really bad, its documentation is worse (another thing that applies to OpenSSL in general). Try to help that a little bit by making it more explicit that you are supposed to call EC_KEY_check_key() after using lower-level EC_KEY setters. Also make it clearer that the setters copy the data, they don't take ownership (which isn't obvious from the naming). If OpenSSL 3 got one thing kind of right, it was to deprecate the EC_KEY and EC_POINT APIs. But if you are going to deprecate something, you should either be prepared to remove it or have a reasonable replacement... Found by Guido Vranken using cryptofuzz https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=66667 ok jsing
* Document a portability caveat about GeneralizedTime and UTCTimejob2024-02-131-2/+9
| | | | OK tb@
* Merge OBJ_NAME_do_all*(3) into EVP_CIPHER_do_all(3)tb2024-01-315-63/+96
| | | | | | | This is the only OBJ_NAME API that will remain after the next major bump. The API is misnamed and really is about EVP, so move it to an EVP manual documenting another API doing essentially the same thing. Remove most cross references to OBJ_NAME_*.
* Make it safe to delete entries from an lhash doall callback.jsing2024-01-241-11/+4
| | | | | | | | | | | | | | | | | | Currently, the callback cannot safely delete entries as it could lead to contraction of the hash table, which in turn could lead to doall skipping entries (and that typically leads to memory leaks). The recommended workaround is to reach in and fiddle with the hash table internals in order to prevent contraction, call the doall function and then restore the internals that were changed. Rather than just improving our documentation, actually make it safe to delete entries from an lhash doall callback by pausing contractions prior to starting the callback loop, then restoring the down load factor and triggering contraction once completed. This means that callers no longer need access to change hash table internals in order to achieve this same behaviour. ok tb@
* Link CMS_signed_add1_attr(3) to tree structure of crypto(3) manuals andtb2024-01-223-5/+8
| | | | add a back reference from CMS_get0_SignerInfos(3).
* Simplify history section to match what other manuals dotb2024-01-221-23/+2
|
* Document various CMS_{signed,unsigned}_* functionsjob2024-01-222-1/+393
| | | | | | These functions change signed & unsigned attributes of a CMS SignerInfo object With & OK tb@
* Remove check{,obj_cleanup}_defer documentationtb2024-01-131-66/+3
| | | | | | | | | Both check_defer() and the global variable obj_cleanup_defer were removed from the public API two years ago. Now they were removed from the internals as well, simplifying the cleanup process greatly. We no longer need them to have a chance to understand the cleanup process. Also remove references to EVP_cleanup() since this has long been deprecated and now it doesn't clean up things anymore.
* 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
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-05 02:52:58 +0000