| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
| |
constants after these have been marked as intentionally undocumented;
they are internal to the library and unused in the wild
|
| |
|
| |
|
|
|
|
| |
with job
|
|
|
|
|
|
| |
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@.
|
|
|
|
|
|
|
|
|
| |
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@.
|
|
|
|
| |
(Many examples in this directory are really bad. This is no exception.)
|
|
|
|
|
| |
and purge the superseded information from the algorithm-independent
page EVP_PKEY_new(3).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@.
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
function EVP_MD_CTX_init(3) and talk about EVP_MD_CTX_new(3) instead.
This is similar in spirit to OpenSSL commit 25191fff (Dec 1, 2015),
but i'm also mentioning EVP_MD_CTX_reset(3), slightly reordering some
sentences in a more systematic way, and improving some related wordings
to be more precise and read better.
|
|
|
|
| |
mentioned in NAME and described in DESCRIPTION and RETURN VALUES.
|
| |
|
| |
|
|
|
|
|
| |
the important manual page EVP_EncryptInit(3). Belatedly adjust some
cross references.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
X509_LOOKUP_by_subject() was made internal a while back. Its documentation
was very detailed, so this was a bit of a tangle to undo.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Sadly, it's going to go away before ever having become the default.
|
|
|
|
|
|
|
|
| |
Loosely based on the OpenSSL 1.1 documentation but extended quite a bit to
explain what the flags mean and what info they do (and do not) convey. With
the usual valuable feedback from jmc.
ok jmc
|
|
|
|
| |
The existing description was lacking and incorrect, respectively.
|
|
|
|
| |
reminded by mandoc -Tlint
|
|
|
|
| |
Remove the corresponding documentation.
|
|
|
|
|
|
|
|
| |
According to some, a fail-open password verification function is par for
the course for libcrypto. Unfortunately, we have been recommending its use
over similarly named EVP functions after what amounted to a coin toss a
few years back. Luckily enough, no one followed that advice and we can
soon remove this API for good.
|
|
|
|
|
| |
This API family has been neutered and will be removed in the next bump.
Further cross references will be untangled in the future.
|
|
|
|
|
| |
These functions have been disabled for a while and they will be removed
in the next major bump.
|
| |
|
|
|
|
|
|
|
| |
Some macros are still exposed, but apart from the loss of a very nice way
of saying "this is completely misdesigned, overengineered and not properly
thought through" the only thing we would have learned from it is that this
stuff is "probably useless".
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This uses the same language in most manuals mentioning the obsolete
ENGINE parameters. Make it clear that it is always ignored and that
NULL should be passed. Always call it engine instead of a mix of e
pe, impl, eng.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
missed in 2022 "remove please from manual pages" commit
ok tb@
|