summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Remove DECLARE_STACK_OF(ASN1_STRING_TABLE)tb2024-03-021-4/+1
| | | | | | Another remnant of the unused ASN1_STRING_TABLE extensibility goes away. ok jsing
* Remove ASN1_STRING_TABLE_{add,cleanup}tb2024-03-025-27/+3
| | | | | | | This was API for the ASN1_STRING_TABLE extensibility which has been neutered for months and was completely unused in the ecosystem. ok jsing
* const correct ASN1_STRING_TABLE_get()tb2024-03-022-7/+6
| | | | | | | | The ability of modifying the ASN1_STRING_TABLE was removed and the table is now static. Stop casting away const. The only consumer, security/xca, is already fixed. ok jsing
* Add mkdtemps(3), like mkdtemp(3) but with a suffix.millert2024-03-012-8/+32
| | | | OK deraadt@ tb@
* Fix OPENSSL_{gmtime,timegm} in namespace buildtb2024-03-012-4/+3
| | | | | These were incorrectly added to asn1.h. OPENSSL_gmtime is in crypto.h and OPENSSL_timegm is already in posix_time.h
* Remove the ciphers_by_values_test()tb2024-03-011-56/+0
|
* exporter: use the atrocious SSL_CIPHER_find() rather than get_by_id()tb2024-03-011-2/+5
|
* ssltest: drop another use of CRYPTO_mem_leaks()tb2024-03-011-2/+1
|
* Detect OPENSSL_NO_GOST correctlytb2024-02-291-1/+2
|
* CRYPTO_mem_leaks* will go away. Remove calls in legacy teststb2024-02-293-6/+3
|
* Link x509_algor test statically and switch to the internaltb2024-02-292-9/+18
| | | | X509_ALGOR_set0_evp_md()
* OBJ_NAME_TYPE_PKEY_METH is no longer supportedtb2024-02-291-5/+1
|
* Stop testing EVP_PKEY_GOST{IMIT,R01}tb2024-02-291-3/+1
|
* Prepare freenull test for GOST removaltb2024-02-291-1/+3
|
* Expand only ever user of PBEPARAM_free() outside of libcryptotb2024-02-281-2/+3
|
* Small tweak for X509_check_purpose()tb2024-02-281-4/+6
| | | | ok jsing
* Use an accessor instead of reaching into X509_PURPOSEtb2024-02-281-2/+2
| | | | ok jsing
* align read-only sections on masm/windows to 64 bytesbcook2024-02-271-1/+9
| | | | | | | Avoid conflicts where alignment is specified later in the underlying assembly. ok tb@
* Neuter OBJ_bsearch{_,ex_}()tb2024-02-262-31/+40
| | | | | | | | | Make these functions always fail. A copy of OBJ_bsearch_ex_() is kept in stack.c, where it is still used by internal_find() for sk_find{,_ex}(). sk_find_ex() will be removed in the upcoming bump, and then we can simplify or rewrite what's still needed. ok jsing
* Add a few missing endbr64 to libcryptotb2024-02-242-0/+6
| | | | | | | | gcm_{gmult,ghash}_4bit(), aesni_ccm64_decrypt_blocks(), aes_cbc_encrypt(), and aesni_xts_{en,de}crypt() were overlooked in previous passes. Found with a diff for ld.lld by kettenis ok kettenis
* Replace uses of endbr64 with _CET_ENDBR from cet.htb2024-02-2430-110/+132
| | | | | | | | | cet.h is needed for other platforms to emit the relevant .gnu.properties sections that are necessary for them to enable IBT. It also avoids issues with older toolchains on macOS that explode on encountering endbr64. based on a diff by kettenis ok beck kettenis
* Remove custom key length handlingtb2024-02-241-5/+1
| | | | | | | | | | | No cipher in libcrypto is marked EVP_CIPH_CUSTOM_KEY_LENGTH and no control handler deals with EVP_CTRL_SET_KEY_LENGTH, which means that this code is dead as far as libcrypto is concerned. Almost nothing uses EVP_CIPHER_meth* (this was added for a single project) and nothing sets a custom ctrl. This isn't going to change anyway since EVP_CIPHER_meth* is deprecated in order to promote more provider beauty. ok beck jsing
* Remove last calls to CRYPTO_{push,pop}_info()tb2024-02-241-9/+3
| | | | | | | These don't do anything but return 0 and will be garbage collected in the upcoming bump. ok jsing
* err.c: fix incorrect line wrappingtb2024-02-241-5/+5
|
* Prepare to provide X509_STORE_get1_objects()tb2024-02-234-3/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The OpenSSL 1.1 API X509_STORE_get0_objects() is not thread safe. It exposes a naked internal pointer containing certificates, CRLs and cached objects added by X509_LOOKUP_hash_dir(). Thus, if the store is shared between threads, it is not possible to inspect this pointer safely since another thread could concurrently add to it. This may happen in particular during certificate verification. This API led to security issues in rust-openssl and is also problematic in current Python. Other consumers of X509_STORE_get0_objects() are haproxy, isync, openvpn. The solution is to take a snapshot of the state under a lock and return that. This is what X509_STORE_get1_objects() does. It returns a newly allocated stack that needs to be freed with sk_X509_OBJECT_pop_free(), passing X509_OBJECT_free as a second argument. Based on a diff by David Benjamin for BoringSSL. https://boringssl-review.googlesource.com/c/boringssl/+/65787 ok beck jsing PS: Variants of this have landed in Python and OpenSSL 3 as well. There the sk_*deep_copy() API is used, which in OpenSSL relies on evaluating function pointers after casts (BoringSSL fixed that). Instead of using this macro insanity and exposing that garbage in public, we can do this by implementing a pedestrian, static sk_X509_OBJECT_deep_copy() by hand.
* Remove ASN1_time_clamp_notafter() prototypetb2024-02-231-3/+1
| | | | | There is now a prototype in x509_internal.h, so no need to repeat that here.
* x509_asid: NULL out min/max on extract_min_max() failuretb2024-02-201-1/+3
| | | | requested by/ok jsing
* x509_asid: fix some KNF botchestb2024-02-191-37/+19
| | | | | | | | When this file was brought into KNF, a few things became particularly ugly. This makes {a,b}{,_{min,max}} have function scope in canonize/is_canonical, which removes unfortunate line wraps and some other silliness. ok job
* pk7_attr.c: tidy includestb2024-02-191-6/+4
|
* asn1time: remove some debugging codetb2024-02-181-3/+1
|
* Tweak previoustb2024-02-181-7/+6
|
* Adjust regress test for memset() requested by jsing on reviewtb2024-02-181-4/+18
|
* Add regress coverage for the new APItb2024-02-182-2/+197
| | | | | This exercises the new API, in particular with respect to overflow behavior around the years 0/9999, which are special for GeneralizedTime/X.509.
* Update ASN1_TIME_set(3)tb2024-02-181-5/+44
| | | | | | | Document OPENSSL_{posix_to_tm,tm_to_posix}() and fix the documentation of OPENSSL_{gmtime,timegm}(). ok jsing
* Add posix_time.h from BoringSSLtb2024-02-188-60/+160
| | | | | | | | | | | | | | | | This is prepares to expose some internal API as OPENSSL_tm_to_posix() and OPENSSL_posix_to_tm(). They will be used in libtls and ocspcheck(8) to get rid of the portability nightmare that is timegm(). Also fix the location of OPENSSL_gmtime() and OPENSSL_timegm() (this API is not yet exposed). The former is from OpenSSL and surprisingly lives in crypto.h, not asn1.h, and the latter is BoringSSL API and lives in the new posix_time.h. Initial diff from beck, this pulls in further upstream work after review feedback. ok jsing
* Align EVP_CIPHER_CTX_init() and _legacy_clear()tb2024-02-181-2/+2
|
* Hide EVP_{CIPHER,MD}_CTX_init() from internalstb2024-02-181-1/+5
| | | | ok jsing
* Use EVP_MD_CTX_legacy_clear() internallytb2024-02-1812-33/+33
| | | | ok jsing
* Use EVP_CIPHER_CTX_legacy_clear() internallytb2024-02-185-13/+13
| | | | ok jsing
* Add EVP_MD_CTX_legacy_clear()tb2024-02-182-2/+9
| | | | | | | | | This is analogous to EVP_CIPHER_CTX_legacy_clear() and will serve as an internal replacement for EVP_MD_CTX_init() until the conversion to heap allocated ctx is completed. This way EVP_MD_CTX_init() can be changed to match the OpenSSL 1.1 API. ok jsing
* Add EVP_CIPHER_CTX_legacy_clear()tb2024-02-182-2/+10
| | | | | | | | | | | | | | OpenSSL 1.1 made EVP_CIPHER_CTX_init() an alias of EVP_CIPHER_CTX_reset(). In particular, it changed signature and it would no longer leak internal state if used on an already used ctx. On the other hand, it can't be used for ctx on the stack. libcrypto still has a few ctx on the stack which will be converted to heap allocated contexts at some point. Until this is completed, we will use EVP_CIPHER_CTX_legacy_clear() internally, so that the public API can be changed to match OpenSSL 1.1. ok jsing
* Use calloc() instead of malloc() in BIO_new().jsing2024-02-171-16/+5
| | | | ok tb@
* Inline and disable BIO_set().jsing2024-02-161-21/+19
| | | | | | | | BIO_set() is a dangerous function that cannot be used safely. Thankfully, the only consumer is BIO_new(), hence inline the functionality and disable the BIO_set() function (for complete removal in the near future). ok tb@
* Use 'bio' more consistently for function arguments.jsing2024-02-161-58/+61
| | | | | | | | Rather than 'a' or 'b', use 'bio' more consistently - there are still some more complex cases that have been left alone for now. Also use fewer parentheses. No change to generated assembly other than line numbers.
* Make it explicit that the EC_KEY setters don't check thingstb2024-02-161-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While EC_POINT_set_affine_coordinates() checks that the resulting point is on the elliptic curve, this is only necessary, but not sufficient, to ensure that the point can serve as a valid public key. For example, this does not check for normalized coordinates or exclude that it is zero (the point at infinity). Such checks, and more, are performed by the similarly named EC_KEY_set_public_key_affine_coordinates(). This kind of makes sense from the mathematical standpoint as an elliptic curve point isn't a priori a public key, even if you are not going to use libcrypto for actual mathematics (or anything really) unless you like pain. In a cryptographic library such differences are more of a hazard than a help. This is exacerbated by the fact that EC_KEY_set_public_key() does almost no checking (it only checks that the point's EC_POINT method matches the one of group set of the EC_KEY, which is far from enough). The API expects that you call EC_KEY_check_key() on your own. This is kind of confusing since EC_KEY_set_public_key_affine_coordinates() does that for you. Unfortunately, adding sanity checks to EC_KEY_set_public_key() isn't easy since it's going to penalize those who already check. Caching the result of a check is dangerous and fragile if there are a million ways of fiddling with an EC_KEY. While the elliptic curve code is really bad, its documentation is worse (another thing that applies to OpenSSL in general). Try to help that a little bit by making it more explicit that you are supposed to call EC_KEY_check_key() after using lower-level EC_KEY setters. Also make it clearer that the setters copy the data, they don't take ownership (which isn't obvious from the naming). If OpenSSL 3 got one thing kind of right, it was to deprecate the EC_KEY and EC_POINT APIs. But if you are going to deprecate something, you should either be prepared to remove it or have a reasonable replacement... Found by Guido Vranken using cryptofuzz https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=66667 ok jsing
* BIO_dump*() avoid signed integer overflowtb2024-02-151-1/+10
| | | | | | | | | This API returns an int encoding the number of bytes printed. Thus, a dump of a large enough byte string can make this overflow and rely on undefined behavior. With an indent of 64, as little as 26 MB is enough to make this happen. ok jsing
* Document a portability caveat about GeneralizedTime and UTCTimejob2024-02-131-2/+9
| | | | OK tb@
* bio_dump: add a test that prints all values of a single bytetb2024-02-091-1/+59
|
* Remove a useless EVP_MD_CTX_init() calltb2024-02-091-2/+1
| | | | | The hash was just created with EVP_MD_CTX_new(), so we memset a calloced piece of memory to 0.
* Cope with recent ctype.h prefix changes.anton2024-02-051-5/+5
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-31 16:12:31 +0000