On Wed, May 20, 2020 at 05:41:46PM -0400, Wietse Venema wrote: > Rich Felker: > [dnssec end-to-end probe, log a warning if for any reason results > do not have the authentic data' bit set]'. > > This sounds like a great plan that will also mitigate the problem of > > glibc's AD-stripping by default. FYI I've raised concerns about that > > again on libc-alpha: > > > > https://sourceware.org/pipermail/libc-alpha/2020-May/114174.html > > > > > Postfix would still disable the res_nxxx() calls into libc-musl, but > > > that would be safe, even if those calls end up to get added later. > > > > Can you do this via the published __RES API version in resolv.h, > > rather than probing ldd? The latter is flaky and will get wrong result > > in various cases I mentioned before. > > The test for res_nxxx() support needs to be at build time, because > the build fails when the library does not define the res_nxxx() > API.
Right, this is a build time test. #if defined(__RES) && __RES < 19991006 #define NO_RES_NFUNCS #endif > (Also, you stated that runtime libraries may arbitrarily differ in > feature set from the build-time library. In that light, the only > safe choice is to never call the res_nxxx() API.) Behaviors, but not symbols. If you use a symbol that's only available in a newer library version, the program will fail to execute if only the old library is available. If you build with the old library version that doesn't have the new symbol, it will also run with the new library version, and just won't use the new feature. But in any case musl does not have these functions or plan to add them soon since the normal non-n ones are stateless and thread-safe and the "n" ones expose a really sloppy internal-state structure with IPv6 compatibility problems and other issues, and even if we do add them it will be safe to keep using the non-n functions. > Given that __RES is a number, how would one encode that MUSL > supports the res_nxxx() API, and not screw up other code?? > > The __RES value varies wildly between different platforms. __RES > never changes for glibc, but it does change on other platforms. > > #define __RES 19991006 // Fedora 30, glibc 2.29 > #define __RES 19991006 // Alpine 3.11.5, pretends-to-be glibc 2.29 > #define __RES 19991006 // Fedora 32beta, glibc 2.31 > #define __RES 20030124 // FreeBSD 8 > #define __RES 20090302 // FreeBSD 12 > > All of the above implement res_nxxx() except the pretends-to-be glibc 2.29. musl defines: #define __RES 19960801 and this is what I see on my Alpine system too. They don't have any patch changing it. The "n" functions were added to glibc in 1999 with commit b43b13ac2544b11f35be301d1589b51a8473e32b. This commit seems to have first appeared in glibc 2.2. I'm not sure why you think 2.29 didn't have them. Rich
