summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Document X509v3_{addr,asid}_subset.3 take two (missed cvs add)tb2023-09-281-0/+176
| | | | | | First RFC 3779 page without a BUG section. It could have one, but I'm in a lenient mood right now. Maybe it's just that this is bad but not quite as bad as EVP.
* Document X509v3_{addr,asid}_subset.3tb2023-09-287-30/+40
| | | | | | First RFC 3779 page without a BUG section. It could have one, but I'm in a lenient mood right now. Maybe it's just that this is bad but not quite as bad as EVP.
* Fix EVP_CIPHER_CTX_iv_length()tb2023-09-284-9/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In today's episode of "curly nonsense from EVP land" we deal with a quite harmless oversight and a not too bad suboptimal fix, relatively speaking. At some point EVP_CIPHER_{CCM,GCM}_SET_IVLEN was added. It modified some object hanging off of EVP_CIPHER. However, EVP_CIPHER_CTX_iv_length() wasn't taught about this and kept returning the hardcoded default value on the EVP_CIPHER. Once it transpired that a doc fix isn't going to cut it, this was fixed. And of course it's easy to fix: you only have to dive through about three layers of EVP, test and set a flag and handle a control in a couple methods. The upstream fix was done poorly and we begrudgingly have to match the API: the caller is expected to pass a raw pointer next to a 0 length along with EVP_CIPHER_GET_IV_LENGTH and the control handler goes *(int *)ptr = length in full YOLO mode. That's never going to be an issue because of course the caller will always pass a properly aligned pointer backing a sufficient amount of memory. Yes, unlikely to be a real issue, but it could have been done with proper semantics and checks without complicating the code. But why do I even bother to complain? We're used to this. Of note here is that there was some pushback painting other corners of a bikeshed until the reviewer gave up with a resigned That kind of changes the semantics and is one extra complexity level, but [shrug] ok... Anyway, the reason this matters now after so many years is that rust-openssl has an assert, notably added in a +758 -84 commit with the awesome message "Docs" that gets triggered by recent tests added to py-cryptography. Thanks to Alex Gaynor for reporting this. Let me take the opportunity to point out that pyca contributed to improve rust-openssl, in particular its libressl support, quite a bit. That's much appreciated and very noticeable. Regress coverage to follow in subsequent commits. Based on OpenSSL PR #9499 and issue #8330. ok beck jsing PS: A few macros were kept internal for now to avoid impact on the release cycle that is about to finish. They will be exposed after release.
* RFC 3779: stop pretending we support AFIs other than IPv4 and IPv6tb2023-09-271-19/+28
| | | | | | | This code is a complete bug fest and using it with any other AFI is downright dangerous. Such don't arise in this context in practice. ok claudio jsing
* Various small tweaks in the RFC 3779 docstb2023-09-276-58/+69
| | | | Mention a few more bugs and unify manpage descriptions
* Document X509v3_{addr,asid}_inherits(3)tb2023-09-266-5/+140
| | | | Also note another bug in X509v3_asid_{canonize,is_canonical}(3).
* Document X509v3_addr_get_{afi,range}(3)tb2023-09-264-5/+142
|
* Document the guts of RFC 3779 IPAddrBlockstb2023-09-266-13/+534
| | | | Let's just say there's room for improvement...
* Missing variable name in prototypetb2023-09-261-2/+2
|
* Fix section title of X.690 reference (missing article)tb2023-09-261-3/+3
|
* Document some barely usable parts of the ASIdentifiers API.tb2023-09-263-18/+184
| | | | | Someone clearly didn't actually use much of the code they wrote and exposed and therefore didn't think it through properly.
* sorttb2023-09-251-2/+2
|
* New manual page documenting the usual four ASN.1 functions for bothtb2023-09-254-3/+263
| | | | ASRange and ASIdOrRange
* tweak wording and fix a typotb2023-09-251-3/+3
|
* Tiny tweaks: missing article, capitalize a word and change an Xrtb2023-09-252-5/+5
|
* Document the RFC 3779 extensions as supportedtb2023-09-251-2/+5
|
* Add initial documentation for the RFC 3779 APItb2023-09-255-5/+889
| | | | | | | | This documents the part of the API that allows building the two extensions. It is all very complicated and the bug density is quite high. Surely there's lots of room for improvement, but I've been sitting way too long on versions of these. I'll never finish. Let's fix and improve in tree.
* Break two ridiculously long lines in ec_pub_cmp() and ec_cmp_parameters()tb2023-09-241-4/+7
|
* Refactor eckey_{param2type,type2param}()tb2023-09-241-92/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EC key parameters can be determined by an OID or they can be explicitly encoded. The confusingly named eckey_{param2type,type2param}() decode a new EC key from either form of parameters, or they encode a given key's parameters in the proper way. Signature and semantics are all over the place. It also features an inlined version of EC_KEY_new_by_curve_name(). This commit brings some order into this mess. Parameters are given by a pair (ptype, pval), where the ptype is either V_ASN1_OBJECT for OID encoding or V_ASN1_SEQUENCE for explicit encoding. Accordingly, the void pointer pval is an ASN1_OBJECT or an ASN1_STRING. These pairs are abstracted away in the X509_ALGOR object. The library decides whether a given EC key uses OID or explicit parameter encoding using the asn1_flag on the EC key's internal EC_GROUP, i.e., the object representing its curve. If this flag is set, the OID is determined by the nid returned by EC_GROUP_get_curve_name(). Add 'mutually inverse' pairs of functions eckey_{to,from}_params() which wrap eckey_{to,from}_object() and eckey_{to,from}_explicit_params(). This way the EC ameth pub and priv key de/encoding functions can transparently translate from/to an X509_ALGOR object. Of course, this is just an intermediate step and if you look closely you notice const weirdness (due to the fact that the carefully planned and executed const rampage missed the ECParameters API) and all sorts of other things that need to be fixed. Who would bat an eye lid? It wouldn't be visible amid all the twitching anyway. ok jsing
* Bump LibreSSL versiontb2023-09-201-3/+3
|
* aesni_ctr32_encrypt_blocks() is called indirectly from C code, so itderaadt2023-09-181-0/+1
| | | | | needs endbr64 ok kettenis tb
* PEM_def_callback(3) does not truncate its argument but merely the copy,schwarze2023-09-181-15/+21
| | | | plus a few wording improvements
* Rewrite RSA_get_ex_new_index(3) and CRYPTO_set_ex_data(3) from scratch.schwarze2023-09-182-462/+753
| | | | | | | | | The defects of the old pages were too numerous to list in full but included vagueness, gaps, misleading statements, bad ordering, and duplication. Use my Copyright since none of the text we inherited from OpenSSL remains. Without doing a thorough review, tb@ thinks he likes the new pages after quickly reading through both of them.
* replace the outdated statement that everything uses SHA-1schwarze2023-09-131-5/+33
| | | | by a table showing the supported algorithms
* Document the special meaning of NID_undef in this context.schwarze2023-09-131-4/+13
| | | | | | | | From Matt Caswell <matt at openssl dot org> via OpenSSL commit 1212818e (Sep 11, 2018) from the OpenSSL 1.1 branch, which is still under a free license. Wording slightly tweaked by me.
* Various improvements:schwarze2023-09-131-15/+63
| | | | | | | | * Document the ASN1_PKEY_CTRL_DEFAULT_MD_NID control operation. * Mention that EVP_PKEY_asn1_new(3) sets ASN1_PKEY_DYNAMIC. * Fix the description of EVP_PKEY_asn1_copy(3), which was totally wrong. * Warn about the crazy ASN1_PKEY_DYNAMIC handling in EVP_PKEY_asn1_free(3). * Be more precise about EVP_PKEY_asn1_new(3) RETURN VALUES.
* document the EVP_PKEY_ASN1_METHOD flagsschwarze2023-09-131-5/+51
| | | | ASN1_PKEY_ALIAS, ASN1_PKEY_DYNAMIC, and ASN1_PKEY_SIGPARAM_NULL
* minor markup fixes: add one missing .Dv and one missing .Vt macroschwarze2023-09-131-4/+8
|
* document the EVP_PKEY_CTRL_MD and EVP_PKEY_CTRL_GET_MD command constantsschwarze2023-09-131-4/+35
|
* fix typoschwarze2023-09-121-2/+2
|
* document the four EVP_PKEY_OP_TYPE_* mask constantsschwarze2023-09-121-4/+23
|
* document sizes for ED25519 and X25519,schwarze2023-09-121-6/+19
| | | | including the constants ED25519_KEYLEN and X25519_KEYLEN
* document the constant EVP_CHACHAPOLY_TLS_TAG_LENschwarze2023-09-122-3/+9
|
* Document EVP_AEAD_DEFAULT_TAG_LENGTH and EVP_AEAD_MAX_TAG_LENGTH,schwarze2023-09-121-5/+20
| | | | making some adjacent wordings slightly more precise.
* fix the vague and misleading description of the EVP_MD_FLAG_* constantsschwarze2023-09-121-22/+72
|
* Small cleanups in cms_sd_asn1_ctrl():tb2023-09-111-6/+6
| | | | Compare explicitly against NULL and use ret instead of i.
* Rewrite CMS_SignerInfo_{sign,verify}()tb2023-09-111-61/+55
| | | | | | | | | Convert to using one-shot signing and verification. This is simpler than doing Init/Update/Final and necessary for Ed25519 support (RFC 8419). Use a single exit idiom, don't reuse the same buffer for decoding and signing and simplify a few other things. ok jsing
* spellingjsg2023-09-111-3/+3
|
* Back out superfluous initializationjob2023-09-111-5/+4
| | | | requested by jsing@
* Make EVP_PKEY_get1_$TYPE a wrapper of EVP_PKEY_get0_$TYPEtb2023-09-101-22/+29
| | | | | | | Avoids a bit of code duplication and reduces the probability of a fix being applied to only one of get0 and get1 (which happend in p_lib.c r1.35). ok jsing
* EVP_CipherInit(): use EVP_CIPHER_CTX_cleanup()tb2023-09-101-3/+3
| | | | | | | | | | | | | | | | Before EVP_CIPHER_CTX was opaque, callers could pass an uninitialized ctx into EVP_CipherInit() and calling EVP_CIPHER_CTX_cleanup() on such a ctx would end in tears. The only way to initialize a ctx is by way of EVP_CIPHER_CTX_new(), on which we can call EVP_CIPHER_CTX_cleanup() and avoid silly leaks on ctx reuse. This also allows some simplifications in the documentation. There are more changes of this kind that should be done all over libcrypto. They will be tackled in subsequent commits. "makes a lot of sense" schwarze ok jsing
* Mention EVP_PKEY_encrypt_old(3) and EVP_PKEY_decrypt_old(3) becauseschwarze2023-09-101-7/+87
| | | | | | | some software still calls them. Put them here because despite the function and header names, they are really specific to RSA. Besides, this avoids a distraction in the more important EVP_PKEY_encrypt(3) and EVP_PKEY_decrypt(3) manual pages.
* Briefly mention SSLeay_add_all_algorithms(3) becauseschwarze2023-09-101-6/+18
| | | | | | | | surprisingly large numbers of software packages still call it. Mark the unused aliases OPENSSL_add_all_algorithms_conf(3), OPENSSL_add_all_algorithms_noconf(3), SSLeay_add_all_ciphers(3), and SSLeay_add_all_digests(3) as intentionally undicumented.
* Document the deprecated functions EVP_set_pw_prompt(3) andschwarze2023-09-101-71/+86
| | | | | | | | | | | | | | | | EVP_get_pw_prompt(3) because some software out there still uses them. While here, also improve the description of EVP_read_pw_string(3). Delete documentation for des_read_pw(3) and des_read_pw_string(3). They couldn't be used in LibreSSL since at least 2016 because they were never in Symbols.list, and in 2022, jsing@ also removed them from <openssl/ui_compat.h>. Delete the misleading AUTHORS section. Richard Levitte did not write the original implementation of these functions, and the compatibility wrapper around the UI_process(3) API that he did write is not notable enough to be mentioned so prominently.
* Mark EVP_ENCODE_LENGTH() and EVP_DECODE_LENGTH() as intentionallyschwarze2023-09-101-2/+6
| | | | | | | undocumented because they do not describe properties of the Base64 encoding but add arbitrary constant lengths, hence being implementation details of BIO_f_base64(3). Besides, they are practically unused outside evp/bio_b64.c.
* fix Xr punctuationjsg2023-09-101-3/+3
|
* spellingjsg2023-09-102-6/+6
|
* new manual page EVP_PKEY_CTX_get_operation(3),schwarze2023-09-094-5/+127
| | | | also documenting EVP_PKEY_CTX_get0_pkey(3)
* document EVP_PKEY_CTX_get_data(3) and EVP_PKEY_CTX_set_data(3)schwarze2023-09-091-6/+58
|
* Document EVP_PKEY_CTX_set0_keygen_info(3).schwarze2023-09-091-10/+59
| | | | | | While here, also add the missing RETURN VALUES entries for EVP_PKEY_gen_cb(3), EVP_PKEY_CTX_get_cb(3), and EVP_PKEY_CTX_get_keygen_info(3).
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-05-18 02:26:51 +0000