openbsd/src, branch libressl-v3.8.3A mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=libressl-v3.8.32023-10-03T09:58:06+00:00Fix a typo and move a word2023-10-03T09:58:06+00:00tb2023-10-03T09:58:06+00:00urn:sha1:08e7cae74e8cb6e634c1d7425b6fed61c8069f5aAdd some coverage for ASN1_TIME_cmp_time_t() as well2023-10-02T11:14:15+00:00tb2023-10-02T11:14:15+00:00urn:sha1:bd4c65ab446591df390d1c9860be1c6932bc7c99
ASN1_UTCTIME_cmp_tim_t() could be done similarly, but then I have to mess
with LIBRESSL_INTERNAL. Let's do this after unlock.
Add regress coverage for ASN1_TIME_compare()2023-10-02T10:40:43+00:00tb2023-10-02T10:40:43+00:00urn:sha1:774c2629b7cc4b1e6db48beed1fc69ed6f35dd3cMinor asn1time tweaks2023-10-02T09:42:58+00:00tb2023-10-02T09:42:58+00:00urn:sha1:ba67bb45759c955aca3a3fcafa46e1eda2106d4b
Sprinkle some (static) const and garbage collect an unused struct.
Example code tweak: do not hardcode the size of array2023-10-01T22:46:21+00:00tb2023-10-01T22:46:21+00:00urn:sha1:e238d8127f4b481f01fc931c4df0d81b341e9953Fix a copy-paste bug in ASN1_TIME_compare()2023-10-01T22:14:36+00:00tb2023-10-01T22:14:36+00:00urn:sha1:801723e5c82440629905965bd58e34dc2f2d62a7
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 values2023-10-01T18:23:50+00:00tb2023-10-01T18:23:50+00:00urn:sha1:14325811a46be3e6d6d9a2f3e7431ed8789a08ed
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 to2023-10-01T10:51:19+00:00tb2023-10-01T10:51:19+00:00urn:sha1:2877b0c96c385a58189dc0d110887eadd2730d0e
crypto(3)
Improve a code comment in the EXAMPLES section2023-10-01T08:29:12+00:00tb2023-10-01T08:29:12+00:00urn:sha1:741f3b8e0f4b440e8a7a379659d9b42a1c849f79Refer to RFC 3779, 2.1.2 for encoding of ranges2023-10-01T08:23:58+00:00tb2023-10-01T08:23:58+00:00urn:sha1:7a28ba92270c2d6ff7cbe1a97e60c85f1e516c5e
Mention sections 2.1.1 and 2.1.2 in STANDARDS