[MacPorts] #49007: openssh @7.1p1 +ldns SSHFP DNSSEC validation fails

[MacPorts]

#49007: openssh @7.1p1 +ldns SSHFP DNSSEC validation fails
-------------------------------+----------------------
  Reporter:  scott-macports@…  |      Owner:  ionic@…
      Type:  defect            |     Status:  assigned
  Priority:  Normal            |  Milestone:
 Component:  ports             |    Version:  2.3.3
Resolution:                    |   Keywords:  haspatch
      Port:  openssh ldns      |
-------------------------------+----------------------

Comment (by scott-macports@…):

 Replying to [comment:1 raimue@…]:
 > I agree with the [https://bugzilla.mindrot.org/show_bug.cgi?id=2119#c1
 upstream answer]. Was this ever reported to ldns upstream?

 (sorry I didn't answer earlier, been busy with other projects :)

 I looked into submitting a patch to ldns upstream, and created a working
 patch before realizing that I would break existing users of libldns (for
 example, drill) if it was applied.

 Basically, ldns_resolver_new_frm_file() loads policy from a file (as the
 name suggests), one specifically documented to be /etc/resolv.conf if the
 filename parameter is NULL (which is how it's currently called from
 openssh).

 drill uses this function if it's called without a server parameter, and
 the use of /etc/resolv.conf may be overridden with the -c parameter

 If drill is run with a server, ldns_resolver_new() is used and no default
 anchors are loaded -- and then only if in chase/trace mode, and no other
 keys are yet loaded, it specifically loads /etc/unbound/root.key as it's
 default.

 Basically, drill expects to the ldns interface to allow all loaded keys to
 be configurable at runtime, with no "magic policy" loading keys from files
 that it can't override.  If I modified ldns_resolver_new_frm_file() to
 load keys from, say, /etc/trusted-key.key, then users of drill (and
 possibly other library clients) couldn't control the keys they were using
 from parameters, breaking use cases where specific keys need to be loaded
 (eg testing or private roots).

 I could, of course, submit a new interface to ldns that explicitly loaded
 default keys from /etc/trusted-key.key (or some other default), but then
 openssh couldn't use that interface until the new library version was
 available on any particular distribution (as a new api, it can't really be
 backported as fix to distributions using the current or older libraries),
 preventing a working openssh + ldns on those systems for some time...

 That leaves the final option, which is to use libldns the way drill does,
 and load policy from the files explicitly specified... and we're back to
 not being able to modify the default (/etc/resolv.conf) because OSX won't
 let us.

 I agree that having a general purpose "just resolve my hostname" interface
 that loaded keys and policy from reasonable defaults might be a useful
 interface for ldns to have, but we'd need to get that added, and then we
 could use it when compiled against a recent enough version -- in the
 meantime, the only way we can get a working ldns library on OSX is to load
 the keys with ldns_resolver_push_dnssec_anchor()

 I'll submit this analysis to the upstream openssh bug, but again OSX is
 hit harder than other platforms at the moment as we can't modify the
 /etc/resolv.conf config file to add a trust anchor, so we need a fix for
 that.

-- 
Ticket URL: <https://trac.macports.org/ticket/49007#comment:4>
MacPorts <https://www.macports.org/>
Ports system for OS X