From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25114 invoked from network); 19 May 2020 14:00:33 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 19 May 2020 14:00:33 -0000 Received: (qmail 26387 invoked by uid 550); 19 May 2020 14:00:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26354 invoked from network); 19 May 2020 14:00:28 -0000 Date: Tue, 19 May 2020 10:00:16 -0400 From: Rich Felker To: postfix-users@postfix.org Cc: musl@lists.openwall.com Message-ID: <20200519140015.GO21576@brightrain.aerifal.cx> References: <20200413193505.GY11469@brightrain.aerifal.cx> <20200413214138.GG41308@straasha.imrryr.org> <20200414035303.GZ11469@brightrain.aerifal.cx> <20200414061620.GI41308@straasha.imrryr.org> <20200414160641.GC11469@brightrain.aerifal.cx> <20200414215951.GJ41308@straasha.imrryr.org> <20200519013734.GL21576@brightrain.aerifal.cx> <20200519023814.GN68966@straasha.imrryr.org> <20200519054427.GN21576@brightrain.aerifal.cx> <20200519090610.GO68966@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200519090610.GO68966@straasha.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [musl] 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