A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.3.5 2021-09-30T18:28:20+00:00 2021-09-30T18:28:20+00:00 deraadt 2021-09-30T18:28:20+00:00 urn:sha1:83bc5cc5ee52fc0847ad86d9499c1ac8b9de9fe0 ok sthen, beck, jsing, tb, etc etc This cannot be issued as an errata/syspatch, because syspatch cannot 2021-09-30T18:25:43+00:00 deraadt 2021-09-30T18:25:43+00:00 urn:sha1:8e81e40d0c1296f1862d4a6749edd4cba53c4a23 In order to work around the expired DST Root CA X3 certficiate, enable X509_V_FLAG_TRUSTED_FIRST in the legacy verifier. This means that the default chain provided by Let's Encrypt will stop at the ISRG Root X1 intermediate, rather than following the DST Root CA X3 intermediate. Note that the new verifier does not suffer from this issue, so only a small number of things will hit this code path. ok millert@ robert@ tb@ this is errata 6.9/018_cert 2021-09-26T14:07:40+00:00 deraadt 2021-09-26T14:07:40+00:00 urn:sha1:35f8ef07a93e59616eb96dc41d4f8e6a21a6319b The length checks need to be >= rather than > in order to ensure the string remains NUL terminated. While here consistently check wi before using it so we have the same idiom throughout this function. Issue reported by GoldBinocle on GitHub. ok deraadt@ tb@ this is 6.9 errata 017 2021-08-20T19:54:59+00:00 benno 2021-08-20T19:54:59+00:00 urn:sha1:3627e057ddf00759d5985e80a8bb317a1b071a4a X509_CERT_AUX_print(). Commit in -current: CVSROOT: /cvs Module name: src Changes by: schwarze@cvs.openbsd.org 2021/07/10 11:45:16 Modified files: lib/libcrypto/asn1: t_x509a.c Log message: Fix a read buffer overrun in X509_CERT_AUX_print(3), which by implication also affects X509_print(3). The ASN1_STRING_get0_data(3) manual explitely cautions the reader that the data is not necessarily NUL-terminated, and the function X509_alias_set1(3) does not sanitize the data passed into it in any way either, so we must assume the alias->data field is merely a byte array and not necessarily a string in the sense of the C language. I found this bug while writing manual pages for these functions. OK tb@ As an aside, note that the function still produces incomplete and misleading results when the data contains a NUL byte in the middle and that error handling is consistently absent throughout, even though the function provides an "int" return value obviously intended to be 1 for success and 0 for failure, and even though this function is called by another function that also wants to return 1 for success and 0 for failure and even does so in many of its code paths, though not in others. But let's stay focussed. Many things would be nice to have in the wide wild world, but a buffer overflow must not be allowed to remain in our backyard. This is patches/6.9/common/015_x509.patch.sig 2021-04-15T16:43:29+00:00 cvs2svn admin@example.com 2021-04-15T16:43:29+00:00 urn:sha1:c2b3f6b6c35da44086594c7eb521632b73980275 2021-04-15T16:43:27+00:00 tb 2021-04-15T16:43:27+00:00 urn:sha1:e8f5d300c023c6ce39600d797f14aad30480c218 2021-04-15T16:40:32+00:00 tb 2021-04-15T16:40:32+00:00 urn:sha1:d9e6b3c687e1354c4e1cad55cbcab90c57b88e22 2021-04-15T16:35:54+00:00 tb 2021-04-15T16:35:54+00:00 urn:sha1:f84b114c13dd506177484d1d3d884decd7f8fc49 2021-04-15T16:30:14+00:00 tb 2021-04-15T16:30:14+00:00 urn:sha1:e3838fdc2a1003bcdb4b3974b84cac83f1360f3f 2021-04-15T16:13:22+00:00 tb 2021-04-15T16:13:22+00:00 urn:sha1:ac21a57498563a5b644578b3012a2748d9c5eee0