On Tue, May 19, 2020 at 10:28:57AM -0400, Rich Felker wrote:
> 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.
So long as they don't remove support for the new functionality, there's
no problem. Users will only get DANE support in Postfix + MUSL if
the C library version is high enough.
Again, it is fine if DANE support is disabled, the users will deploy a
system where it is not (a later base, before patches, version of MUSL),
if they care enough.
What is NOT fine, is believing that DANE is enabled and working when the
library simply ignores RES_USE_DNSSEC.
Postfix MUST disable DANE support on such systems. Please provide a
static compile-time mechanism to determine whether the platform's libc
will return the AD from the local resolver when RES_USE_DNSSEC is set
(perhaps provide a new macro we can test for at compile-time).
We could perhaps indeed call res_mkquery and look whether the AD bit is
set in the header, though this is rather complicated, because many
systems will instead set the DO bit in the EDNS header, and so we'd
need to parse the query, check the additional section looking for an OPT
RR with the DO bit set.
I am not particularly keen on doing this. Rather, if you're claiming to
support RES_USE_DNSSEC, but not actually setting the DO bit, please
provide a macro that indicates you'll be setting the AD bit instead, and
we can test for that at build time.
--
Viktor.
