summaryrefslogtreecommitdiff
path: root/src (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge X509_VERIFY_PARAM_ID into X509_VERIFY_PARAMtb2023-05-284-110/+73
| | | | | | | | | | Back in the day when essentially every struct was open to all applications, X509_VERIFY_PARAM_ID provided a modicum of opacity. This indirection is now no longer needed with X509_VERIFY_PARAM being opaque itself, so stop using X509_VERIFY_PARAM_ID and merge it into X509_VERIFY_PARAM. This is a first small step towards cleaning up the X509_VERIFY_PARAM mess. ok jsing
* Implement SHA256_{Update,Transform,Final}() directly in sha256.c.jsing2023-05-271-4/+103
| | | | | | | | | | m32_common.h is a typical OpenSSL macro horror show - copy the update, transform and final functions from md32_common.h, manually expanding the macros for SHA256. This will allow for further clean up to occur. No change in generated assembly. ok beck@ tb@
* Add HASH_NO_UPDATE and HASH_NO_TRANSFORM to md32_common.hjsing2023-05-271-5/+7
| | | | | | | This makes it possible to still use minimal parts of md32_common.h, while disabling the update and transform functions. ok beck@ tb@
* Add coverage for calling BN_{dec,hex}2bn() with NULL inputs.jsing2023-05-271-9/+37
|
* Bump LibreSSL versionlibressl-v3.8.0tb2023-05-271-3/+3
|
* Clean up alignment handling for SHA-512.jsing2023-05-272-80/+96
| | | | | | | | | | | This recommits r1.37 of sha512.c, however uses uint8_t * instead of void * for the crypto_load_* functions and primarily uses const uint8_t * to track input, only casting to const SHA_LONG64 * once we know that it is suitably aligned. This prevents the compiler from implying alignment based on type. Tested by tb@ and deraadt@ on platforms with gcc and strict alignment. ok tb@
* Remove malloc interposition, a workaround that was once needed for emacsotto2023-05-271-7/+7
| | | | ok guenther@
* Move verified_chain from SSL to SSL_HANDSHAKEtb2023-05-264-14/+17
| | | | | | | | This is a better version of the fix for the missing pointer invalidation but a bit larger, so errata got the minimal fix. tested by jcs ok jsing
* Forcibly update the EVP_PKEY's internal keyop2023-05-251-13/+25
| | | | | | | | | | | | | | | | | | | | | | | | To aid privilege separation, libtls maintains application-specific data on the key inside the EVP_PKEY abstraction because the EVP API doesn't provide a way to do that on the EVP_PKEY itself. OpenSSL 3 changed behavior of EVP_PKEY_get1_RSA() and related functions. These now return a struct from some cache. Thus, modifying the RSA will no longer modify the EVP_PKEY like it did previously, which was clearly implied to be the case in the older documentation. This is a subtle breaking change that affects several applications. While this is documented, no real solution is provided. The transition plan from one OpenSSL major version to the next one tends to involve many #ifdef in the ecosystem, and the only suggestion provided by the new documentation is to switch to a completely unrelated, new API. Instead, forcibly reset the internal key on EVP_PKEY after modification, this way the change is picked up also by OpenSSL 3. Fixes issue 1171 in OpenSMTPD-portable ok tb@, jsing@
* Update X509_VERIFY_PARAM_inherit() to reflect the change of behaviortb2023-05-241-9/+6
| | | | in x509_vpm.c r1.39.
* Copy the verify param hostflags independently of the host listtb2023-05-242-6/+5
| | | | | | | | | | | | | | | | Without this, hostflags set on the SSL_CTX would not propagate to newly created SSL. This is surprising behavior that was changed in OpenSSL 1.1 by Christian Heimes after the issue was flagged by Quentin Pradet: https://bugs.python.org/issue43522 This is a version of the fix that landed in OpenSSL. There used to be a workaround in place in urllib3, but that was removed at some point. We haven't fixed this earlier since it wasn't reported. It only showed up after recent fallout of extraordinarily strict library checking in urllib3 coming from their own interpretation of the implications of PEP 644. ok jsing
* Add a test to verify that an SSL inherits the hostflags from the SSL_CTXtb2023-05-242-1/+105
| | | | This is currently an expected failure that will be fixed shortly.
* Provide CRYPTO_INT for statically linking libcrypto for libssl regresstb2023-05-241-0/+2
| | | | This will be needed for the ssl_verify_param test
* Provide X509_VERIFY_PARAM_set_hostflags()tb2023-05-241-1/+8
| | | | | | | | This is needed for an upcoming regress test that needs to access the hostflag. This is public API in OpenSSL but since nothing seems to be using this, this accessor will be kept internal-only for the time being. ok jsing
* Simplify OBJ_obj2txt()tb2023-05-232-8/+5
| | | | | | | | | | Instead of adding a NUL termination to OBJ_obj2txt(), move the aobj == NULL or aobj->data == NULL checks to i2t_ASN1_OBJECT_internal(). The only other caller, i2t_ASN1_OBJECT(), fails on aobj == NULL and aobj->length == 0, and the latter condition is implied by aobj->data. Cleaner solution for obj_dat.c r1.52 suggested by/ok jsing
* Add empty line for consistencytb2023-05-231-1/+2
|
* Add regress coverage for obj_dat.c r1.52tb2023-05-231-1/+44
|
* Always NUL terminate buf in OBJ_obj2txt()tb2023-05-231-1/+4
| | | | | | | | | | | OBJ_obj2txt() is often called without error checking and is used for reporting unexpected or malformed objects. As such, we should ensure buf is a string even on failure. This had long been the case before it was lost in a recent rewrite. If obj and obj->data are both non-NULL this is already taken care of by i2t_ASN1_OBJECT_internal(), so many callers were still safe. ok miod
* cms_asn1.c: zap stray tabstb2023-05-231-8/+1
|
* Remove misplaced semicolons in .Fatb2023-05-222-6/+6
|
* ecdhtest: Fix indenttb2023-05-201-2/+2
|
* Remove a space that I thought I had already deleted.tb2023-05-201-2/+2
| | | | Makes mandoc -Tlint happier
* Add a slow regress target that runs openssl speed with proper alignmenttb2023-05-201-2/+7
| | | | | and with an unaligned offset. Let's see if all ciphers on our strict alignment arches can deal with this.
* openssl speed: add an '-unaligned n' optiontb2023-05-202-7/+37
| | | | | | | | | | | | | | | | All hashes and ciphers covered by speed should be able to handle unaligned input and output. The buffers used in openssl speed are well aligned since they are large, so will never exercise the more problematic unaligned case. I wished something like this was available on various occasions. It would have been useful to point more easily at OpenSSL's broken T4 assembly. Yesterday there were two independent reasons for wanting it, so I sat down and did it. It's trivial: make the allocations a bit larger and use buffers starting at an offset inside these allocations. Despite the trivality, I managed to have a stupid bug. Thanks miod. discussed with jsing ok miod
* openssl speed: minor style nitstb2023-05-201-8/+6
| | | | | | | This drops a bunch of unnecessary parentheses, makes the strcmp() checks consistent and moves some "}\n\telse" to "} else". Makes an upcoming commit smaller
* openssl speed: remove binary curve remnantstb2023-05-201-88/+5
| | | | | | | | | | | | | | | This wasn't properly hidden under OPENSSL_NO_EC2M, and all it does now is producing ugly errors and useless "statistics". While looking at this, I found that much of speed "has been pilfered from [Eric A. Young's] libdes speed.c program". Apparently this was an precursor and ingredient of SSLeay. Unfortunately, it seems that this piece of the history is lost. ok miod PS: If anyone is bored, a rewrite from scratch of the speed 'app' would be a welcome contribution and may be an instructive rainy day project. The current code was written in about the most stupid way possible so as to maximize fragility and unmaintainability.
* Add missing rsa_security_bit() handler to the RSA-PSS ASN1_METHODtb2023-05-191-1/+2
| | | | | | Prompted by a report by Steffen Ullrich on libressl@openbsd.org ok jsing
* backout alignment changes (breaking at least two architectures)deraadt2023-05-194-100/+89
|
* Add PROTO_NORMAL() declarations for the remaining syscalls, to avoidguenther2023-05-181-4/+1
| | | | | | | | future, inadvertant PLT entries. Move the __getcwd and __realpath declarations to hidden/{stdlib,unistd}.h to consolidate and remove duplication. ok tb@ otto@ deraadt@
* Use crypto_internal.h's CTASSERT()tb2023-05-172-8/+5
| | | | | | | Now that this macro is available in a header, let's use that version rather than copies in several .c files. discussed with jsing
* Clean up alignment handling for SHA-512.jsing2023-05-172-81/+95
| | | | | | | | | | | | | | | | | | All assembly implementations are required to perform their own alignment handling. In the case of the C implementation, on strict alignment platforms, unaligned data will be copied into an aligned buffer. However, most platforms then perform byte-by-byte reads (via the PULL64 macros). Instead, remove SHA512_BLOCK_CAN_MANAGE_UNALIGNED_DATA and alignment handling to sha512_block_data_order() - if the data is aligned then simply perform 64 bit loads and then do endian conversion via be64toh(). If the data is unaligned then use memcpy() and be64toh() (in the form of crypto_load_be64toh()). Overall this reduces complexity and can improve performance (on aarch64 we get a ~10% performance gain with aligned input and about ~1-2% gain on armv7), while the same movq/bswapq is generated for amd64 and movl/bswapl for i386. ok tb@
* ecdhtest: check malloc() return valuestb2023-05-161-4/+7
| | | | From Ilya Chipitsine
* add missing pointer invalidationjcs2023-05-161-1/+2
| | | | ok tb
* Clean up SHA-512 input handling and round macros.jsing2023-05-161-47/+49
| | | | | | | | | | | Avoid reach around and initialisation outside of the macro, cleaning up the call sites to remove the initialisation. Use a T2 variable to more closely follow the documented algorithm and remove the gorgeous compound statement X = Y += A + B + C. There is no change to the clang generated assembly on aarch64. ok tb@
* Rename arguments of X509_STORE_CTX_init()tb2023-05-141-5/+5
| | | | | | | | | | It is higly confusing to call the list of untrusted certs chain, when you're later going to call X509_STORE_CTX_get0_chain() to get a completely unrelated chain by the verifier. Other X509_STORE_CTX APIs call this list of certs 'untrusted', so go with that. At the same time, rename the x509 into leaf, which is more explicit. suggested by/ok jsing
* Fix X509error() and X509V3error()tb2023-05-141-6/+11
| | | | | | | | | | | | | | | When v3err.c was merged into x509_err.c nearly three years ago, it was overlooked that the code needed two distinct pairs of ERR_FUNC/ERR_REASON, one for ERR_LIB_X509 and one for ERR_LIB_X509V3. The result is that the reason strings for the X509_R_* codes would be overwritten by the ones for X509V3_R_* with the same value while the reason strings for all X509V3_R_* would be left undefined. Fix this by an #undef/#define dance for ERR_LIB_X509V3 once we no longer the ERR_FUNC/ERR_REASON pair for ERR_LIB_X509. reported by job ok jsing
* Send the linebuffer BIO to the attictb2023-05-141-377/+0
| | | | | | | | | | | | | | | | | | | | | *) On VMS, stdout may very well lead to a file that is written to in a record-oriented fashion. That means that every write() will write a separate record, which will be read separately by the programs trying to read from it. This can be very confusing. The solution is to put a BIO filter in the way that will buffer text until a linefeed is reached, and then write everything a line at a time, so every record written will be an actual line, not chunks of lines and not (usually doesn't happen, but I've seen it once) several lines in one record. BIO_f_linebuffer() is the answer. Currently, it's a VMS-only method, because that's where it has been tested well enough. [Richard Levitte] Yeah, no, we don't care about any of this and haven't compiled this file since forever. Looks like tedu's chainsaw got blunt at some point...
* Fix another mandoc -Tlint warningtb2023-05-141-3/+5
| | | | | With this the only -Tlint warnings are about Xr to undocumented functions: EVP_CIPHER_CTX_copy, EVP_CIPHER_CTX_get_cipher_data, X509V3_EXT_get_nid.
* Rephrase a sentence slightly to apease mandoc -Tlinttb2023-05-141-3/+5
|
* Fix Xr as BN_is_prime(3) is in the attictb2023-05-141-3/+3
|
* Zap trailing commatb2023-05-141-2/+2
|
* X509_policy_tree_level_count(3) is gonetb2023-05-141-3/+2
|
* add missing #include <string.h>; ok tb@op2023-05-148-8/+18
|
* Assert that test->want != NULL at this pointtb2023-05-131-1/+3
| | | | Should make coverity happier
* Bob points out that one error should be an X509V3error()tb2023-05-121-2/+2
|
* x509_utl.c: fix some style nits.tb2023-05-121-4/+3
|
* Rewrite string_to_hex() and hex_to_string() using CBB/CBStb2023-05-121-70/+124
| | | | | | | | | | | These helpers used to contain messy pointer bashing some with weird logic for NUL termination. This can be written more safely and cleanly using CBB/CBS, so do that. The result is nearly but not entirely identical to code used elsewhere due to some strange semantics. Apart from errors pushed on the stack due to out-of-memory conditions, care was taken to preserve error codes. ok jsing
* asn1oct: add a couple more teststb2023-05-121-1/+10
|
* Reduce the number of SHA-512 C implementations from three to one.jsing2023-05-121-134/+1
| | | | | | | | | | | | | | | | | We currently have three C implementations for SHA-512 - a version that is optimised for CPUs with minimal registers (specifically i386), a regular implementation and a semi-unrolled implementation. Testing on a ~15 year old i386 CPU, the fastest version is actually the semi-unrolled version (not to mention that we still currently have an i586 assembly implementation that is used on i386 instead...). More decent architectures do not seem to care between the regular and semi-unrolled version, presumably since they are effectively doing the same thing in hardware during execution. Remove all except the semi-unrolled version. ok tb@
* asn1oct: minor tweak in error messagetb2023-05-121-3/+3
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-28 02:42:53 +0000