[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20200519200831.GF1079@brightrain.aerifal.cx>
Date: Tue, 19 May 2020 16:08:32 -0400
From: Rich Felker <dalias@...c.org>
To: Postfix users <postfix-users@...tfix.org>
Cc: musl@...ts.openwall.com
Subject: 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
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.
