summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/bn/arch/amd64 (unfollow)
Commit message (Collapse)AuthorFilesLines
25 hoursMake truncation in ASN1_BIT_STRING_set_bit() explicittb1-9/+43
Instead of relying on i2c_ASN1_BIT_STRING() to determine the "unused" bits on encoding, set them explicitly in abs->flags via a call to asn1_abs_set_unused_bits(). This means ASN1_STRING_FLAGS_BITS_LEFT is now set on a bit string, which was previously explicitly cleared. This also means that the encoding of a non-zero ASN1_BIT_STRING populated by setting the bits individually will now go through the if (a->flags & ASN1_STRING_FLAG_BITS_LEFT) path in i2c_ASN1_BIT_STRING(). The most prominent usage of this function is in X.509 for the keyUsage extension or the CRL reason codes. There's also the NS cert type, TS PKIFailureInfo and general BITLIST config strings. The reason for the truncation logic comes from the DER for NamedBitLists X.690, 11.2.2 below: X.680, 22.7: When a "NamedBitList" is used in defining a bitstring type ASN.1 encoding rules are free to add (or remove) arbitrarily any trailing 0 bits to (or from) values that are being encoded or decoded. Application designers should therefore ensure that different semantics are not associated with such values which differ only in the number of trailing 0 bits. X.690, 11.2.2 Where ITU-T Rec. X.680 | ISO/IEC 8824-1, 22.7, applies, the bitstring shall have all trailing 0 bits removed before it is encoded. Note 1 - In the case where a size constraint has been applied, the abstract value delivered by a decoder to the application will be one of those satisfying the size constraint and differing from the transmitted value only in the number of trailing zero bits. Note 2 - If a bitstring value has no 1 bits, then an encoder shall encode the value with a length of 1 and an initial octet set to 0. ok kenjiro (on an earlier version) jsing
42 hoursreplace buggy strncmp with strcmp found with clang-tidybcook1-2/+2
Found the same fix from davidben in BoringSSL as well (https://boringssl-review.googlesource.com/c/boringssl/+/87927). OpenSSL appears to have accidentally changed the semantics here with the HAS_PREFIX macro, which appears to be incorrect. discussed w/ tb@ & beck@
8 daysImplement s_client starttls protocol sieve.martijn2-4/+62
OK on previous diff concept sthen@ Suggestions, feedback and OK current diff tb@
9 daysopenssl asn1pars: move tmplen next to tmpbuftb1-4/+4
9 daysopenssl asn1pars: avoid a few unnecessary caststb1-11/+11
If str is a const unsigned char * rather than a char *, we can get away with a single cast and do not need to cast away const either. Reduce the scope of tmpbuf and ctmpbuf (now p) while there. ok kenjiro
10 daysEVP_SealInit.3: fix RETURN VALUES sectiontb1-2/+12
While normal calls return 0 for error and npubk for success, there is a case where it returns the usual 1/0 thing. Make that explicit. Prompted by a report by Niels Dossche ok jsing kenjiro
10 daysEVP_OpenInit.3: fix RETURN VALUES sectiontb1-6/+4
This has been incorrectly documented since forever. The function only ever returned 0/1. ok jsing kenjiro
10 daysEVP_SealInit(): clear random key on exittb1-2/+4
ok jsing kenjiro
10 daysEVP_{Open,Seal}Init(): remove redundant EVP_CIPHER_CTX_reset() callstb1-5/+1
The subsequent EVP_{Decrypt,Encrypt}Init_ex() calls already do that. pointed out by jsing
10 daysEVP_SealInit(): minor cleanup.tb1-11/+25
Explicitly compare pointers against NULL, turn the function into single exit, add hint at why npubk <= 0 or pubk == NULL are a success path: The documentation briefly explains that EVP_OpenInit() and EVP_SealInit() is able to initialize the EVP_CIPHER_CTX in two steps exactly like the EVP_CipherInit_ex() API they wrap: the first call with non-NULL cipher (aka type) only sets the cipher on the ctx, then it returns to allow callers to customize the EVP_CIPHER_CTX, and a second call with cipher == NULL skips the initialization and finishes the ctx setup by setting key and iv. Prompted by a report by Niels Dossche. ok jsing kenjiro
10 daysEVP_SealInit: do not return -1 on errortb1-2/+2
It is documented that EVP_SealInit() returns 0 on error. So -1 is wrong. Reported by Niels Dossche ok jsing kenjiro
10 daysEVP_OpenInit(): minor cleanuptb1-9/+16
Explicitly compare pointers against NULL, turn the function into single exit and explain why priv == NULL is a success (hint: muppet API). Prompted by a report by Niels Dossche. ok jsing kenjiro
13 daysAvoid type confusion in the timestamp response parsingtb1-1/+3
A malformed v2 signing cert can lead to a type confusion, and the result is a read from an invalid memory address or NULL, so a crash. Unlike for OpenSSL, v1 signing certs aren't affected since miod fixed this in '14. Reported by Luigino Camastra, fix by Bob Beck, via OpenSSL, CVE 2025-69420. ok jsing
13 daysAvoid type confusion in PKCS#12 parsingtb1-3/+9
A type confusion can lead to a 1-byte read at address 0x00-0xff, so a crash. Reported by Luigino Camastra, fix by Bob Beck, via OpenSSL, CVE 2025-22795 ok jsing
13 daysAdd NULL pointer check to PKCS12_item_decrypt_d2i()tb1-1/+6
Avoids a NULL pointer dereference triggerable by a malformed PCKS#12 file. From Luigino Camastra via OpenSSL (CVE-2025-69421) ok jsing
2026-01-25assembly regress: use make's MACHINE_ARCH rather than handrolling ittb1-4/+3
discussed with jsing
2026-01-25Fix tyojsing1-2/+2
2026-01-25Hook assembly regressjsing1-1/+2