summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/man/EVP_CIPHER_CTX_ctrl.3 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Fix RETURN VALUES for EVP_CIPHER_CTX_ctrl(3)tb9 days1-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)
* Move the algorithm-specific functions EVP_rc2_*(3) out of EVP_EncryptInit(3)schwarze2024-12-081-3/+5
| | | | | | | | | 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 EVP_CIPHER_CTX_iv_length() return valuestb2023-10-011-3/+7
| | | | | | | | | | | | We aligned with upstream behavior. Let's document it properly. Surprisingly, OpenSSL 1.1 half-assed the docs: two parts of the manual contradict each other. The part getting EVP_CIPHER_CTX_iv_length() right, incorrectly documents possible -1 return value to EVP_CIPHER_iv_length(). OpenSSL 3 documentation improvement efforts seem to have tried to address this issue with the result that the manual is now entirely wrong when it comes to the EVP_CIPHER_CTX_iv_length() replacement. Par for the course.
* Split three new manual pages EVP_CIPHER_nid(3), EVP_CIPHER_CTX_ctrl(3),schwarze2023-08-311-0/+260
and EVP_CIPHER_CTX_set_flags(3) out of the excessively large and unwieldy EVP_EncryptInit(3). This causes a number of inaccuracies and gaps to stand out, but i'm not mixing text changes or content additions into this split. Using very useful feedback from tb@ regarding what belongs together and how important the various functions are. I refrained from bothering him with the complete patch, but he likes the general direction.