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 31720 invoked from network); 19 May 2020 20:08:54 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 19 May 2020 20:08:54 -0000 Received: (qmail 19881 invoked by uid 550); 19 May 2020 20:08:48 -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 19846 invoked from network); 19 May 2020 20:08:46 -0000 Date: Tue, 19 May 2020 16:08:32 -0400 From: Rich Felker To: Postfix users Cc: musl@lists.openwall.com Message-ID: <20200519200831.GF1079@brightrain.aerifal.cx> References: <20200519154542.GC1079@brightrain.aerifal.cx> <49RN803wcfzJrNv@spike.porcupine.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49RN803wcfzJrNv@spike.porcupine.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [musl] Re: Outgoing DANE not working On Tue, May 19, 2020 at 01:25:52PM -0400, Wietse Venema wrote: > Rich Felker: > > 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. > > A pointer to how one would use the updated code would be welcome, > perhaps a pointer to the submit message. https://git.musl-libc.org/cgit/musl/commit/?id=fd7ec068efd590c0393a612599a4fab9bb0a8633 > I won't comment on distro maintainers who willingly break Postfix's > security guarantees of DANE, without informing the user. I'm not encouraging any to do that; rather I've encouraged them to take measures to both: (1) ensure that DANE is not silently ignored, by either patching Postfix to work with old musl (prior to the above commit) or patching the musl package and adding a dependency from the postfix package on the updated musl package, and: (2) not ship Postfix packages with DNSSEC/DANE disabled, because that would encourage admins to switch DANE off in their config files to "fix the breakage" after upgrading, then forget to turn it back on once updated packages are available to make it work. I haven't been through this with other distros yet, but Alpine folks were committed to both of these principles. Rich