summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/man (follow)
Commit message (Collapse)AuthorAgeFilesLines
* EC_POINT_new: wording tweaks in the BUGS sectiontb2025-05-181-6/+6
|
* Garbage collect docs of BIO_dump{,_indent}_{cb,fp}()tb2025-05-091-35/+3
| | | | | The _cb() variants were only documented as intentionally undocumented. Be that as it may, they left the building more than a year ago.
* Fix up two markup mistakes with .Fn and .Xrtb2025-05-041-4/+4
|
* More space around .Dl + a typo on toptb2025-05-012-5/+11
|
* EC_GROUP_check.3: rephrase a sentence to avoid a word repetitiontb2025-04-281-4/+4
|
* EC_GROUP_new_by_curve_name.3: escape a - in code.tb2025-04-281-3/+3
|
* EC_POINT_point2oct: remove in_ prefix in RETURN VALUEStb2025-04-261-5/+5
|
* EC_GROUP_new_curve_GFp: some fixes in the RETURN VALUE sectiontb2025-04-261-9/+12
|
* Fix markup for EC_GROUP_set_point_conversion_formtb2025-04-261-4/+5
|
* Fix up a few dangling referencestb2025-04-254-13/+12
|
* Rework EC documentationtb2025-04-2513-1242/+1998
| | | | | | | | | | | | | | | | | | | | | | | | | | This replaces the giant, poor quality and outdated EC_GROUP_copy.3, EC_GROUP_new.3, and EC_POINT_new.3 manuals with seven new manuals written from scratch. * EC_GROUP_new_by_curve_name() is the entry point for builtin curves, * EC_GROUP_new_curve_GFp() describes lower level API that should not usually be needed apart from a handful of accessors. * EC_GROUP_check() contains two functions that applications should not need because either you know for certain something is an elliptic curve (so these checks are pointless) or you should not use it. * EC_GROUP_get_curve_name() describes some low level ASN.1 footguns and corresponding getters. * EC_POINT_new() contains the simple EC_POINT allocation and freeing API * EC_POINT_get_affine_coordinates() contains the coordinate accessors * EC_POINT_point2oct() is about encoding elliptic curve points While all this is quite far from perfect, the diff is getting too big and it will be easier to improve this in tree. It is definitely more repetitive than I would like it to be. Reviews, tweaks and general feedback are of course welcome. discussed with jsing
* BN_new: zap an anachronistic admonitiontb2025-04-251-4/+2
| | | | | | | | | -This type should be considered opaque and fields should not be modified -or accessed directly. The type has long been opaque and reasonable people will not do things that permit them to access the fields of opaque types directly. Of course, in the vicinity of OpenSSL code and API all sorts of insanity actually exist.
* Use hyphenated spelling for the SHAs except for the APItb2025-04-1712-41/+42
| | | | | The mix of SHA256 and SHA-256 is jarring, so use FIPS's spelling. Leave HMAC-SHA256 as it is and fix a nearby RIPEMD-160.
* Fix RETURN VALUES for EVP_CIPHER_CTX_ctrl(3)tb2025-03-251-9/+4
| | | | | | | | | | | | | | | The current documentation was clearly incorrect since a return of -1 from the methods is explicitly intercepted and translated to 0. schwarze and I both audited the tree and concluded that only 0 and 1 is possible. OpenSSL 3 broke this API contract and now has explicit return -1 in the convoluted 200-line maze this simple function has become with recent provider improvements. So add a small sentence hinting at that. Nobody will be surprised to read that with OpenSSL's characteristic penchant for needless inconsistency the return value checks in their tree are all over the place and sometimes incorrect. ok schwarze (with two tweaks)
* Rename a bunch of confusingly named variablestb2025-03-151-6/+6
| | | | | | Variables of the type serialized or deserialized are called val_in or val_out in all other manuals, so align this page to using those rather than the confusing X509_CRL **der_out, etc.
* const correct d2i_* prototypestb2025-03-144-13/+13
|
* X509_NAME_print_ex: zap stray commatb2025-03-091-2/+2
|
* Fix documented signature of UI_OpenSSL()tb2025-03-091-3/+3
|
* Fix documented signature of BN_MONT_CTX_copy()tb2025-03-091-3/+3
|
* X509_NAME_print_ex.3: move s to the proper placetb2025-03-091-2/+2
|
* Remove mention of X509_NAME_print(3) in the docstb2025-03-093-46/+13
|
* Adjust signature of CRYPTO_set_mem_functions and remove _get_ docstb2025-03-081-23/+5
|
* Rename CRYPTO_get_mem_functions.3 to CRYPTO_set_mem_functions.3tb2025-03-082-4/+4
|
* Remove EC_POINT_method_of() docstb2025-03-081-19/+1
|
* 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
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-25 09:13:14 +0000