summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Unlock CRYPTO_LOCK_UI on ui_open_session() failuretb2026-07-251-3/+5
| | | | | | | | | | | | | | | | | | | | | Both ui_open_session() implementations, open_console() in ui_openssl.c in base, and the one in ui_openssl_win.c in portable, grab the lock of type CRYPTO_LOCK_UI before doing anything else. The only internal (and, as far as I can tell, the only existing) caller, UI_process(), returns immediately on failure. The calling thread thus keeps holding the lock and the next call to UI_process() will block indefinitely. Fix this by using the common exit path, which calls ui_close_session() aka close_console(), both implementations of which release the lock. Thanks to Kartik (@sage-mode-hunter) who proposed an alternative fix for ui_openssl_win.c, which we would have to apply to ui_openssl.c as well. Matches OpenSSL behavior since PR #2037 Closes https://github.com/libressl/portable/pull/1334 ok kenjiro
* Improve SHA-3 performance.jsing2026-07-221-37/+281
| | | | | | | | | | | Replace the tiny-sha3 keccakf implementation with an unrolled and interleaved algorithm, that is hidden away in an obsolete reference implementation. This gets us 3.3x speed up on arm64 (Apple M2), a 1.3x speed up on amd64 (Intel i7-1165G7) and 6x speed up on sparc64 (M3000). ok tb@
* Remove redundant BIO_write() length assertions in b64_write()kenjiro2026-07-171-3/+1
| | | | | | | | | b64_write() asserted that BIO_write() does not return more bytes than requested in two places. Other BIO_write() call sites do not make this check, and there is no special handling here that depends on asserting this condition. ok tb@ beck@ joshua@
* Fix X.509 constraints URI host parsing.jsing2026-07-141-29/+72
| | | | | | | | | | | | | | | An authority in a URI is only terminated by a slash, question mark or hash, however the current code also included colons. This allows a specically crafted userinfo to bypass name constraints host checks. Additionally, IPv6 literals may only be specified when enclosed with square brackets, which is not enforced. Rewrite parts of the host and IP parsing code to be more strict, fixing both of these issues in the process. Thanks to Jack Lloyd for reporting the userinfo bypass. ok tb@
* correspondigly -> correspondinglytb2026-07-131-1/+1
|
* x509_vfy: sync get_crl_sk() with BoringSSL and OpenSSLtb2026-06-261-6/+18
| | | | | | | | | | | | Among CRLs with the same score prefer the one with the most recent lastUpdate (RFC 5280 thisUpdate). This pulls in OpenSSL commits 626aa248, e032117d, 8b7c51a0 from 2016, so before the license change. This uses the annoying ASN1_TIME_diff() API, but there is no better way, really. Every other ASN1_TIME API will be just as awkward. This fixes the currently failing x509_crl test cases. ok kenjiro
* Add OIDs for CCR, ErikIndex, ErikPartition, CommunityDefinitionjob2026-06-252-0/+10
| | | | | | | | | References: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-ccr https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-erik-protocol https://datatracker.ietf.org/doc/html/draft-ietf-grow-yang-bgp-communities OK tb@
* crl_cb(): fix EXFLAG_CRITICAL mishandlingtb2026-06-231-2/+2
| | | | | | | | | The EXFLAG_CRITICAL should be set on encountering a critical CRL extension unsupported by the library. The current loop does the opposite: it stops looking as soon as it finds the first critical extension the library supports... ok kenjiro
* x509_vfy: make a NULL check explicittb2026-06-221-2/+2
|
* x509_vfy: remove unnecessary NULL checks before freetb2026-06-221-7/+4
| | | | looks good to claudio
* x509_vfy: another function pointer argument causing shadowing issuestb2026-06-221-3/+3
|
* bio_meth: rename function pointer arguments to avoid stdio.h shadowingtb2026-06-221-9/+9
|
* conf_api: remove a bunch of redundant parenthesestb2026-06-221-13/+14
|
* x509_verify: fix incorrect purpose check in the non-legacy pathtb2026-06-101-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | If a purpose is configured on the verify context (which it currently never is), this check would only accept certificates for which the purpose check fails. Also, this code is not currently reachable from public API since x509_verify() is only ever called with a legacy xsc set on the verify ctx, so x509_verify_ccert_extensions() takes the path returning 1 earlier. X509_check_purpose() is one of these strange legacy APIs. It returns -1 on error, 0 if the cert fails the purpose check, 1 if it passes it and values between 2 and 5 indicate various legacy garbage meaning that the cert might possibly have been fit for this purpose until around a quarter century ago. While for CA certs the checks in "No we don't care about ..." exclude return values > 1, it is still possible for the S/MIME purpose to return 2 due to a workaround for some buggy NS certs, for example. In short: anything but 1 means unfit for the purpose or at best dubious, so reject such certs. Reported by Frank Denis ok kenjiro
* Avoid freeing a caller-owned buffer in PKCS7_verify()tb2026-06-091-7/+7
| | | | | | | | If a PKCS#7 S/MIME message comes with an empty set of digestAlgorithms in the SignedData, PKCS7_verify() would incorrectly free a caller-owned buffer. Fix the freeing logic to avoid this situation. From Igor Ustinov via OpenSSL
* Add some missing bounds checks to ASN1_mbstring_copy()tb2026-06-091-3/+20
| | | | | | | | | | | | | If the in string is unreasonably long, assigning strlen(in) to an int may overflow, so exclude this situation. Moreover, the code would unconditionally multiply nchar by 2 or 4, which could again overflow an int. Check for this situation and error out to avoid an out of bounds write. More may be needed in here, which will be revisited later. Based on a diff by Viktor Dukhovni via OpenSSL.
* Avoid out-of-bounds read in CMS password-based decryptiontb2026-06-091-1/+5
| | | | | | | | | | The RFC 3211 PWRI integrity check when unwrapping the password-derived key accesses seven bytes from a heap-allocated buffer. If an (invalid) block cipher with short blocks is in use 2 * blocksize may not be sufficient room for 7 bytes. In that silly case, the function performs an OOB read. Add length check to avoid this situation From Igor Ustinov via OpenSSL.
* Avoid NULL dereference in password-based CMS decryptiontb2026-06-091-1/+5
| | | | | | | | The keyDerivationAlgorithm field is OPTIONAL in the ASN.1 but required for password-based CMS. Check that the field is present before using it to avoid a crash. From Igor Ustinov via OpenSSL
* ecdh: add error codes for point at infinity/not on curvetb2026-06-091-3/+7
| | | | | | | | The point at infinity would previously raise EC_R_POINT_AT_INFINITY via EC_POINT_get_affine_coordinates(). For consistency, also raise an error for off-curve points. pointed out by/ok kenjiro
* Fix strange error check in EC_POINT_get_affine_coordinatestb2026-06-091-2/+2
| | | | | | EC_POINT_is_at_infinity() has a Boolean return nowadays, so drop > 0. ok jsing kenjiro
* Add a point at infinity check to ecdh_compute_key()tb2026-06-081-1/+4
| | | | | | | | | | | | | | While we already check that the peer's public point is on the curve and will reject the point at infinity when getting the affine coordinates, doing this earlier avoids doing work with the private key in a clearly invalid case. Suggested by Lucca Hirschi et al. [An EC_KEY_check_key() call was also suggested but this is a bit expensive and punishes callers that do that or equivalent already (e.g. ssh)] ok jsing kenjiro
* ec_convert: point_conversion_t -> point_conversion_form_t in a commenttb2026-06-071-3/+3
|
* remove '#undef _' added for Windows CEjsg2026-05-191-5/+1
| | | | ok jsing@ tb@
* libcrypto/ui: mechanically rename the union _ into utb2026-05-191-29/+29
| | | | | | | | | | | | While mainstream OS use compilers that understand anonymous unions, which would be cleaner here, some special snowflakes rely on LibreSSL in their stacks and they sometimes use very old and special compilers. There is no need to impose a burden on them. There is far more impactful and important cleanup that could be done in the ui pit. This obviates jsg's upcoming removal of a windows-ce workaround. discussed with jsing
* libcrypto/ui: move ui_string_st to ui_lib.c. It's only used there.tb2026-05-192-35/+35
|
* x509_addr: do not call memcmp() on NULLtb2026-05-181-5/+5
| | | | | | | | | | | | | | | | If the minimum length is 0, either a->data or b->data could be NULL, so do not call memcmp() and let the length comparison decide. Doing it this way preserves the RFC 3779, section 2.2.3.3 semantics and avoids the UB. A valid IPAddressFamily has an addressFamily element of 2 or 3 octets: 2 octets for the AFI and 1 octet for the optional SAFI. The check as it is written compares the AFIs and, if they're equal, lets absent SAFI be smaller than any other SAFI. So IPv4 (0x0001) sorts before IPv4 unicast (0x000101) and that in turn sorts before IPv6 (0x0002). Found by beck while breaking OpenSSL ok kenjiro
* x509_prn: zap more than useless commentstb2026-05-161-8/+1
|
* x509_prn: hoist unknown_ext_print() above its only caller; drop prototypetb2026-05-161-29/+25
|
* asn1_print_obstring_ctx: cast to const char * rather than char *tb2026-05-161-2/+2
| | | | Another call to BIO_dump_indent() that cast away const for no good reason.
* unknown_ext_print: avoid casting away consttb2026-05-161-2/+2
| | | | | | | | | The BIO_dump_indent() API masterpiece expects a const char pointer as input. Don't cast away const when suppressing pointer sign warnings. Prompted by a report by N. Dossche ok kenjiro
* Ensure X509V3_EXT_print() only returns 0 and 1tb2026-05-161-3/+3
| | | | | | | | | | | | | | | | | | | In a rare mistake by schwarze, X509V3_EXT_print() is documented to return 0 and 1. This is also what most internal callers expect. However, if either X509V3_EXT_DUMP_UNKNOWN or X509V3_EXT_PARSE_UNKNOWN is set, the extension has an unknown NID or on failure to deserialize the extension value, the return values of BIO_dump_indent() (which is number of bytes written or -1 on error) and ASN1_parse_dump() (which is 0, 1, or 2 on EOC) are propagated. Follow what OpenSSL did and translate to Boolean returns. Error indicators are rather useless here since most errors are ignored anyway. Most callers do if (!X509V3_EXT_print(...)) but they also pass a zero flag. Reported by N. Dossche ok kenjiro
* remove unused ssleay.cnf file; ok tb@jsg2026-05-161-78/+0
|
* ASN1{,_parse}_dump: document return value 2 on EOCtb2026-05-161-3/+7
| | | | | | Prompted by a report by N. Dossche ok kenjiro
* BIO_dump: Xr BIO_printf rather than BIO_write/fwritetb2026-05-161-6/+4
| | | | | | Prompted by a report by N. Dossche ok kenjiro
* Sync cert.pem with mozilla roots; quite a few CA certificates weresthen2026-05-141-1146/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | either removed or distrusted for web so are removed here. ok tb@ Common policies (moz, google, ca/b) are now to distrust roots with key material created before a certain time (currently 2008, this rolls forwards by 2 years each April until 2029 when it moves to '15 years from creation'), and also roots used for TLS are not permitted to be shared with other purposes (Secure Email, Code Signing, or others). This removes all root certificates from the following CA operators: -AffirmTrust - /C=US/O=AffirmTrust/CN=AffirmTrust Commercial - /C=US/O=AffirmTrust/CN=AffirmTrust Networking - /C=US/O=AffirmTrust/CN=AffirmTrust Premium - /C=US/O=AffirmTrust/CN=AffirmTrust Premium ECC -Firmaprofesional SA - /C=ES/O=Firmaprofesional SA/2.5.4.97=VATES-A62634068/CN=FIRMAPROFESIONAL CA ROOT-A WEB -SecureTrust Corporation - /C=US/O=SecureTrust Corporation/CN=Secure Global CA - /C=US/O=SecureTrust Corporation/CN=SecureTrust CA -TeliaSonera - /O=TeliaSonera/CN=TeliaSonera Root CA v1 -Trustwave Holdings, Inc. - /C=US/ST=Illinois/L=Chicago/O=Trustwave Holdings, Inc./CN=Trustwave Global Certification Authority - /C=US/ST=Illinois/L=Chicago/O=Trustwave Holdings, Inc./CN=Trustwave Global ECC P256 Certification Authority - /C=US/ST=Illinois/L=Chicago/O=Trustwave Holdings, Inc./CN=Trustwave Global ECC P384 Certification Authority -certSIGN - /C=RO/O=certSIGN/OU=certSIGN ROOT CA -e-commerce monitoring GmbH - /C=AT/O=e-commerce monitoring GmbH/CN=GLOBALTRUST 2020 ...and some but not all root certificates from these (the ones without - are still remaining): COMODO CA Limited - /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Certification Authority /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification Authority /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority Dhimyotis - /C=FR/O=Dhimyotis/CN=Certigna /C=FR/O=Dhimyotis/OU=0002 48146308100036/CN=Certigna Root CA DigiCert Inc - /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root G2 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root G3 - /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G3 - /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Trusted Root G4 Entrust, Inc. - /C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - for authorized use only/CN=Entrust Root Certification Authority - G2 - /C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Root Certification Authority - EC1 /C=US/O=Entrust, Inc./OU=www.entrust.net/CPS is incorporated by reference/OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification Authority Google Trust Services LLC /C=US/O=Google Trust Services LLC/CN=GTS Root R1 - /C=US/O=Google Trust Services LLC/CN=GTS Root R2 /C=US/O=Google Trust Services LLC/CN=GTS Root R3 /C=US/O=Google Trust Services LLC/CN=GTS Root R4 QuoVadis Limited /C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 1 G3 - /C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2 /C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2 G3 - /C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 3 /C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 3 G3 SwissSign AG - /C=CH/O=SwissSign AG/CN=SwissSign Gold CA - G2 /C=CH/O=SwissSign AG/CN=SwissSign RSA TLS Root CA 2022 - 1 This is based on changes hitting the Mozilla release branch https://raw.githubusercontent.com/mozilla-firefox/firefox/refs/heads/release/security/nss/lib/ckfw/builtins/certdata.txt but the individual commits are easier to see here: https://hg-edge.mozilla.org/projects/nss/log/tip/lib/ckfw/builtins/certdata.txt
* Add a guarded .note.GNU-stack section to crypto assembly files.jsing2026-05-129-9/+45
| | | | | | | | | Add a .note.GNU-stack section to avoid ending up with an executable stack on toolchains that believe we should have an executable stack by default. Reported by ruuda on Github. Discussed with tb@
* Slightly adjust BUGS section for X509_addr_add_range()tb2026-05-101-2/+3
| | | | | Since x509_addr.c r1.95 X509_addr_add_range() clears the unused bits in the maximum, so this is is only true in some implementations.
* PKCS#12: fix erroneous error check in PKCS12_newpass()tb2026-05-091-3/+3
| | | | | | | This is an error I introduced in a refactoring two years ago in r1.20. This means that nothing uses this... From Frank Denis via logan
* Use uint32_t instead of SHA_LONG in the SHA-256 code.jsing2026-05-091-22/+22
| | | | | | | This is more readable and we already have a compile time assert that they are the same size. ok tb@
* Use W rather than X for the SHA-256 message schedule.jsing2026-05-091-83/+83
| | | | | | This more closely matches the SHA-256 specification in FIPS 180-4. ok tb@
* Use consistent variable names in the sha256 code.jsing2026-05-091-67/+67
| | | | | | | Use 'ctx' rather than 'c' for the SHA256_CTX and use data/len rather than d/n. ok kenjiro@ tb@
* Use crypto_add_u32dw_u64() to increment SHA-256 message bit counter.jsing2026-05-091-9/+3
| | | | ok kenjiro@ tb@
* Correct argument type for SHA context.jsing2026-05-091-4/+4
| | | | These are SHA_CTX not SHA256_CTX.
* Correct argument type in comments.jsing2026-05-092-4/+4
|
* remove bogus ifdefs; ok tb@jsg2026-05-081-8/+1
|
* x509_purp: fix doc comment for check_ca()tb2026-05-081-3/+7
| | | | | | | | | | | This comment has gotten out of sync with reality. The "I don't know..." fallback was removed and a special case for netscape CAs was added. Sync from the manual and add some more details. Pointed out by Maximilian Radoy in https://github.com/libressl/portable/issues/1274 ok kenjiro
* Use macros for global functions and objects within SHA assembly.jsing2026-05-079-53/+53
| | | | | | | This lets us remove some of the repetitive statements and allows for them to be adjusted for various platforms. ok kenjiro@ tb@
* Use defines for symbol offsets in aarch64 assembly.jsing2026-05-073-7/+12
| | | | | | These also very between platforms. ok kenjiro@ tb@
* Use defines for text and rodata section names in SHA assembly.jsing2026-05-078-21/+31
| | | | | | These vary between platforms. ok kenjiro@ tb@
* Use a define based instruction separator in SHA assembly.jsing2026-05-079-191/+219
| | | | | | | | Unfortunately, not all assemblers use the same instruction separator. In particular, LLVM on macOS uses %% as an instruction separator, while most other assemblers use a semi-colon. ok kenjiro@ tb@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2026-09-05 20:02:34 +0000