Using bidirectional authentication in pkgng

Michael Gmelin freebsd at
Tue Jan 22 18:30:37 UTC 2013

On Fri, 18 Jan 2013 20:55:40 +0000
Matthew Seaman <m.seaman at> wrote:

> On 18/01/2013 02:57, Michael Gmelin wrote:
> > a. I understand that my use case is not necessarily pkgng's top
> >    priority. Ultimately requirement 2 is pretty nonsensical for
> >    distributing open source packages
> Well, yes.  I must admit that ssh based transport authenticated with
> keys is not top of the list.  Not that we have any objection to
> implementing all sorts of transport schemes, but the libfetch provided
> targets are the easiest and most popular use cases.  If you really
> want this, please open an issue at GitHub.  It will get dealt with
> eventually.  Sooner if anyone wants to send a pull-request.
> > b. It still would be great if sftp could somehow be supported in the
> >    future - or at least some syntax that allows external tools to be
> >    called to accomplish the task. That way people could use sftp,
> > curl or what not to fetch packages.
> Hmmm... it may be possible to implement this sort of thing via a
> suitable modification of the plugin architecture.  Incorporating new
> transport schemes is OK, so long as the code to do it is BSD licensed
> (or something compatible like the MIT or Apache licenses) and it
> doesn't add run-time dependencies to pkgng.  (ie. we have to be able
> to compile it into the binaries so the pkg package can be installed
> standalone.)
> > c. libfetch really needs to get fixed to allow certificate
> > verification in its fetchX* and fetchHTTP* functions when using
> > HTTPS. fetch(3) is based on it and there is no indication anywhere
> > whatsoever that no checks are done at all (none of the libfetch or
> > fetch utility man pages mention it).
> This would be useful functionality to add to libfetch.  However,
> support for DANE (RFC 6698) would be even better, IMHO.

I implemented the necessary bits over the weekend and filed a PR
containing the patch (SSL peer verification, hostname checking, client
certificates etc.).

Assuming the code quality is sufficient, it would be great if it made it
to base (not sure if des at is still taking care of libfetch). 

I agree that implementing DANE would be a good thing. The basic features
I implemented should be in there anyway though, since the current
PKI structure should be supported until something better is around -
DNSSEC adoption itself is still pretty low (at least around here most
hosting companies don't even offer the option) and migration will
probably be a lengthy process. For private CA setups this
solution provides an acceptable level of security anyway.

That said, if there's interest I could volunteer to implement DANE
later this year - assuming there is someone who can audit the


Michael Gmelin

More information about the freebsd-ports mailing list