| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
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.
|