On Tue, May 19, 2020 at 11:11:56AM -0400, Wietse Venema wrote: > Rich Felker: > > On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote: > > > Rich Felker: > > > > The is fundamentally no build-time test possible for this. Even if we > > > > were willing to make flags for each bug (or missing feature) that was > > > > ever fixed indicating the change, that would only tell you whether the > > > > version present at build time had the property, not whether the > > > > version present at runtime does. With a distro, unless the distro > > > > > > If you can provide a libc-musl runtime __version variable, then > > > Postfix can at run time determine that the library supports the > > > necessary functionality, and enable/disable DANE accordingly. > > > > We've been over this countless times from folks requesting version > > numbers. A version number does not tell you what you want to know. > > Distros will patch the functionality into whatever version they're > > shipping. A 1.1.25 (if it ever happens) will likely have the patch > > backported (just applied; no conflict). Querying features has to be > > done on a per-feature basis not based on version numbers. See the > > proposal on libc-coord. > > Do let us know when libc-musl provides an indication whether a DNS > lookup result is authentic (DNSSEC pass).
It is now in master. I've also recommended the patch to Alpine. > Then a year or two later > we can consider to re-enable DANE for libc-musl builds. You're welcome to give us a ping when distros no longer need to patch the broken check out, but I imagine they'll discover this themselves. Rich
