Using bidirectional authentication in pkgng

Michael Gmelin freebsd at
Fri Jan 18 02:57:25 UTC 2013


I'm currently assessing migrating our internal package distribution
infrastructure to pkgng. We run a couple of build hosts that create a
mix of ports based packages and packages created through our own
proprietary build system. Assuming we changed all of this to use
pkgng, we would face the problem of how to distribute packages in a way
that meets the following requirements:

1. The packages shouldn't be tampered with - in addition to signing the
   repo using an RSA key (if that's sufficient anyway) it would be best
   to have some server authentication/trust 

2. The packages shouldn't be requested by an unauthorized host
   Some packages contain licensed software that should not be installed
   on unauthorized hosts. Therefore clients should authenticate
   themselves. Obviously encryption on transport has to be utilized as

My preferred setup would be using sftp with public authentication, since
this is the kind of inter-server trust structure we're using already
anyway. Repo side we would create one user per package-set, allowing
chrooted sftp access (internal-sftp, extremely fast to set up), adding
the public keys of all servers with access to a specific package set to
~/.ssh/authorized_keys. Client side we would accept the repo server's
public key, add a few lines to /root/.ssh/config and set PACKAGESITE to
something like "sftp://myserversip/pkg". A setup that would probably
take less than 10 minutes to accomplish.

Unfortunately right now sftp is not an option in pkgng, fetch
operations are done using libfetch. So the alternative would be using
HTTPS with client certificates. Unfortunately those are not supported
either, so we would have to fallback to using http auth (e.g.
environment variable HTTP_AUTH) with HTTPS. This would work, but
libfetch does not support any form of server certificate
verification/validation (check CN, verify it's a trusted CA etc.) -
which means that the solution would be open to man-in-the-middle
attacks. Assuming the RSA signing mechanism of the repo is reliable
this means that requirement 1 would still be fulfilled, but requirement
2 wouldn't, since intercepting the credentials would be fairly easy to
accomplish in this scenario.

So.. what to make of this?

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

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.

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).

   Afaik base doesn't contain sufficient CA information, so it probably
   would have to rely on a port. What I could imagine is enabling such a
   check by default and allow disabling it through command line
   parameter / environment variable / config file, giving some helpful
   error message on check failure like: "You might want to install

   That way ports and other automated tools could leave it turned off
   by default, but users who use the utility on the command line (or
   tools using libfetch) get actually some basic protection. Client
   certificate support would be nice as well, but.. you know.


Michael Gmelin

More information about the freebsd-ports mailing list