summaryrefslogtreecommitdiff
path: root/src/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Fix a typo and move a wordtb2023-10-031-5/+5
|
* Example code tweak: do not hardcode the size of arraytb2023-10-011-2/+2
|
* Fix a copy-paste bug in ASN1_TIME_compare()tb2023-10-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | ASN1_TIME_compare() compares two times t1 and t2. Due to a copy-paste error, we would do ASN1_time_parse(t1->data, t2->length, &tm2, t2->type) Now if t1 is a UTCTime (length 13) and t2 is a GeneralizedTime (length 15), the worst that could happen is a 2-byte out-of-bounds read. Fortunately, t1 will already have parsed as a UTCTime, so it will have a Z where there should be the first digit of the seconds for a GeneralizedTime and we will error out. Now if both t1 and t2 have the same type, we will parse t1's data twice and we will return an incorrect comparison. This could have some security impact if anything relied on this function for security purposes. It is unused in our tree and unused in our ports tree ports and the only consumer I could find was some MongoDB things doing OCSP, so this won't be too bad. Then of course there's also the language bindings. Issue reported by Duncan Thomson at esri dot com via libressl-security ok beck deraadt
* 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.
* The colons separate the octets, not the digits; add missing link totb2023-10-011-4/+5
| | | | crypto(3)
* Improve a code comment in the EXAMPLES sectiontb2023-10-011-3/+3
|
* Refer to RFC 3779, 2.1.2 for encoding of rangestb2023-10-011-2/+7
| | | | Mention sections 2.1.1 and 2.1.2 in STANDARDS
* Point out that the result of IPAddressRange_new() is an invalid rangetb2023-10-011-3/+3
| | | | since it should be a prefix.
* encoding -> decoding for d2itb2023-10-011-3/+3
|
* Reorder list of additional validation checks neededtb2023-09-301-9/+8
|
* Switch copyright year to 2023.tb2023-09-302-4/+4
| | | | | | | Apparently I should have used 2023 despite sharing versions of these files with several people under this license (and thus permitting them to redistribute and share with the public). It makes no sense to me, but shrug.
* Use addrblocks for .Fatb2023-09-301-2/+2
|
* avoid using the string "a" without markup as a placeholderschwarze2023-09-301-4/+9
| | | | | where that feels potentially confusing, and add one missing .Pp macro; no change of meaning
* consistently use "allow_inherit" for the argument nameschwarze2023-09-301-6/+6
| | | | and fix whitespace on one text line; no change of meaning
* drop one pair of needless parenthesesschwarze2023-09-301-5/+5
| | | | and polish one wording; no change of meaning
* remove a useless repetition of a function nameschwarze2023-09-301-6/+4
| | | | | that was also followed by a bogus argument, and fix one grammatical error; no change of meaning
* polish an awkward wordingschwarze2023-09-301-9/+7
| | | | | and capitalize "AFI" where is does not refer to the function argument; no change of meaning
* two instances of missing .Fa macrosschwarze2023-09-301-13/+15
| | | | and some missing escaping of HYPHEN-MINUS; no text change
* fix one copy and paste error: d2i_*() decode rather than encode;schwarze2023-09-301-7/+7
| | | | plus some minor markup and punctuation fixes
* garbage collect two stray words, no change of meaningschwarze2023-09-301-4/+4
|
* Allow IP addresses to be specified in a URI.beck2023-09-292-15/+20
| | | | | | | | | | | | Our checking here was a bit too aggressive, and did not permit an IP address in a URI. IP's in a URI are allowed for things like CRLdp's AIA, SAN URI's etc.). The check for this was also slightly flawed as we would permit an IP if memory allocation failed while checking for an IP. Correct both issues. ok tb@
* Some wording tweaks to make things a bit more precise.tb2023-09-291-6/+7
|
* Fix a wrong tag and work around an ugly linebreaktb2023-09-291-5/+6
|
* Document X509v3_{addr,asid}_validate_{path,resource_set}(3)tb2023-09-296-10/+217
| | | | | | | These were the last four RFC 3779 things that check_complete.pl x509v3 complained about. I will surely tweak and try to improve a few things in the coming days, but the pages should now be stable enough that review efforts will likely not be wasted. Any feedback appreciated.
* 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
|
* Mention a subtle difference between PEM_def_callback(3) and the example.schwarze2023-09-191-2/+9
| | | | | | | | It's relevant not only for the example, but also because the functions documented here use PEM_def_callback(3) by default, and that exhibits surprising and potentially dangerous behaviour by not NUL-terminating. OK tb@
* Remove the duplicate documentation of pem_password_cb(3).schwarze2023-09-191-56/+94
| | | | | | | | | | | | | | | | | | | While here, also: * Avoid the misleading term "default password callback" because none of the functions in SSL_CTX_use_certificate(3) support overriding it. * Do not talk about "storing", "writing", and "encryption" since the cb passed to SSL_CTX_set_default_passwd_cb(3) is never used for any of that. * List the functions using cb. * Document what happens by default. * Remove the misleading words "which must be provided by the application" because all this is actually optional. * Make several wordings more precise. * Below EXAMPLES, fix argument naming to agree with pem_password_cb(3), clarify the description of what the example does, and, as suggested by tb@, use strlcpy(3). OK tb@
* More 0/NULL confusions in SSL_CTX_new()tb2023-09-191-8/+8
|
* Fix some NULL/0 misspellings in SSL_CTX_new()tb2023-09-191-5/+5
|
* aesni_ctr32_encrypt_blocks() is called indirectly from C code, so itderaadt2023-09-181-0/+1
| | | | | needs endbr64 ok kettenis tb
* remove tls_reset(3) from the NAME, SYNOPSIS, and HISTORY sectionsschwarze2023-09-181-10/+5
| | | | because it is documented in the separate tls_client(3) manual page
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-17 06:35:29 +0000