[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200519140015.GO21576@brightrain.aerifal.cx>
Date: Tue, 19 May 2020 10:00:16 -0400
From: Rich Felker <dalias@...c.org>
To: postfix-users@...tfix.org
Cc: musl@...ts.openwall.com
Subject: Re: Outgoing DANE not working
On Tue, May 19, 2020 at 05:06:10AM -0400, Viktor Dukhovni wrote:
> On Tue, May 19, 2020 at 01:44:30AM -0400, Rich Felker wrote:
>
> > > This sounds reasonable. Will there be a way for Postfix to detect the
> > > new library version, so that we don't disable DANE for musl-libc
> > > versions that do set the AD bit?
> >
> > I'm really disappointed with the detection, which made things much
> > worse by producing postfix builds that won't do DANE even after
> > libc.so is upgraded. It should have just worked after upgrade.
>
> We have no choice, we can't ship code that silently fails to honour its
> configuration. I'm not worried about DANE "working", I'm worried about
> DANE *not* working, and the user being none-the-wiser.
>
> When remote TLSA RRs are published, and DANE is enabled in Postfix, the
> mail must be delivered securely, or the delivery attempt MUST fail.
>
> > The test is also somewhat broken in that it gets the wrong result if
> > /bin/sh is static-linked, or if you have postfix built against musl on
> > a system where /bin/sh is glibc-based, etc. and I don't even know what
> > happens if you're cross-compiling or if that's even supported at all.
>
> A better test would be appreciated. Glibc has GLIBC_PREREQ macros,
> we haven't found anything similar for MUSL.
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
manually makes their package file depend on a particular version of
the distro libc package (which they can do very well, since they know
what patches they applied), it's possible for a user to upgrade
postfix but not libc. And for a user building everything from source
manually, that work's on them.
> > There's not really a "test for versions that do set" by version; I
> > would expect once the patch is upstream and tested, distros like
> > Alpine would just apply it to their existing musl package rather than
> > waiting to upgrade to get it. The only real test is a runtime one,
> > calling res_mkquery and observing that it's set.
>
> Sorry, no such test is possible. There is no reliable canary domain to
> query, and DANE should in any case also work in domains disconnected
> from the Internet, with locally configured trust-anchors.
Canary domain is not needed for a runtime test. All that's needed is a
call to res_mkquery with a dummy domain and inspection of buf[3]. (Of
course you can also just set the bit at query time in exactly the same
manner, but that only works for replacing res_query not res_search. I
don't understand why you're using res_search at all in mail software
though.)
> > BTW I saw in git master you added an additional musl test of the same
> > form for the res_n* APIs. A simpler way to detect them is just with
> > __RES macro in resolv.h, which indicates the supported API version.
> > AIUI it's provided by all known implementations, though I haven't
> > actually checked that.
>
> Robust detection of MUSL features at build time would be much
> appreciated. Precludes any tests that depend on live DNS queries.
> The tests need to *statically* test the features of the platform's
> C library.
This is an area of open cross-implementation effort to provide
something meaningful. See the thread here:
https://www.openwall.com/lists/libc-coord/2020/04/22/1
Note that the "Possibly this should include the semantics for
definition with a value of 0 ("supported for compilation and might or
might not be supported at runtime")..." text applies here since a
static build-time test does not suffice here.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
