A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.5.0 2022-02-06T00:29:02+00:00 2022-02-06T00:29:02+00:00 jsg 2022-02-06T00:29:02+00:00 urn:sha1:330276f39a5e0d5b539d5e8e3e247384f82cbde2 ok jmc@ sthen@ millert@ 2022-01-06T18:58:24+00:00 jmc 2022-01-06T18:58:24+00:00 urn:sha1:bee4e7d6cff50954827dda49f2f9ca3cc0f570b4 from uwe@netbsd -r1.22 ok millert 2021-12-25T01:13:44+00:00 guenther 2021-12-25T01:13:44+00:00 urn:sha1:53c5e2cba9eff61f67c99cd18ea5209d02611f16 2021-12-08T22:06:28+00:00 cheloha 2021-12-08T22:06:28+00:00 urn:sha1:8b24559bc32a8fcd130978a513c42659ebf278de lsearch(3) is really just lfind(3) with an additional branch to append the key if lfind(3) fails. If we get rid of the underlying linear_base() function and move the search portion into lfind(3) and the key-copying portion into lsearch(3) we get smaller and simpler code. Misc. notes: - We do not need to keep the historical comment about errno. lsearch(3) is pure computation and does not set errno. That's really all you need to know. The specification reserves no errors, either. - We are using lfind(3) internally now, so it switches from PROTO_DEPRECATED to PROTO_NORMAL in hidden/search.h and needs DEF_WEAK in stdlib/lsearch.c. With advice from guenther@ on symbol housekeeping in libc. Thread: https://marc.info/?l=openbsd-tech&m=163885187632449&w=2 ok millert@ 2021-12-07T04:01:45+00:00 cheloha 2021-12-07T04:01:45+00:00 urn:sha1:cfc78852fcba382d04261ab49ed38b22e811e417 If the key overlaps the end of the array, memcpy(3) mutates the key and copies a corrupted value into the end of the array. If we use memmove(3) instead we at least end up with a clean copy of the key at the end of the array. This is closer to the intended behavior. With input from millert@ and deraadt@. Thread: https://marc.info/?l=openbsd-tech&m=163880307403606&w=2 ok millert@ 2021-12-02T20:58:01+00:00 cheloha 2021-12-02T20:58:01+00:00 urn:sha1:6cb312a90e0db659665950da1acb2da29d74cadf The "lim" variable needs to be a size_t to match nmemb, otherwise we get undefined behavior when nmemb exceeds INT_MAX. Prompted by a blog post by Joshua Bloch: https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html Fixed by Chris Torek a long time ago: https://svnweb.freebsd.org/csrg/lib/libc/stdlib/bsearch.c?revision=51742&view=markup ok millert@ 2021-11-29T03:20:37+00:00 deraadt 2021-11-29T03:20:37+00:00 urn:sha1:3ff0ca30be40ac85767c463af5dda1f3a1c9fe6e 2021-11-29T01:04:45+00:00 djm 2021-11-29T01:04:45+00:00 urn:sha1:26fe11ace67d4e0ce03ce92e7f81761878ac7047 to 3-term BSD license. 2021-11-24T20:06:32+00:00 jca 2021-11-24T20:06:32+00:00 urn:sha1:757c7646fbdf4543d7d64d84a70fae57d5aa6849 ok florian@ 2021-11-22T20:18:27+00:00 jca 2021-11-22T20:18:27+00:00 urn:sha1:ca02920211b601ee0c85b3f9e9730859d617b1c2 libc can't do DNSSEC validation but it can ask a "security-aware" resolver to do so. Let's send queries with the AD flag set when appropriate, and let applications look at the AD flag in responses in a safe way, ie clear the AD flag if the resolvers aren't trusted. By default we only trust resolvers if resolv.conf(5) only lists name servers on localhost - the obvious candidates being unwind(8) and unbound(8). For non-localhost resolvers, an admin who trusts *all the name servers* listed in resolv.conf(5) *and the network path leading to them* can annotate this with "options trust-ad". AD flag processing gives ssh -o VerifyHostkeyDNS=Yes a chance to fetch SSHFP records in a secure manner, and tightens the situation for other applications, eg those using RES_USE_DNSSEC for DANE. It should be noted that postfix currently assumes trusted name servers by default and forces RES_TRUSTAD if available. RES_TRUSTAD and "options trust-ad" were first introduced in glibc by Florian Weimer. Florian Obser (florian@) contributed various improvements, fixed a bug and added automatic trust for name servers on localhost. ok florian@ phessler@