Date: Tue, 22 Jan 2013 19:30:35 +0100 From: Michael Gmelin <freebsd@grem.de> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: freebsd-ports@freebsd.org Subject: Re: Using bidirectional authentication in pkgng Message-ID: <20130122193035.4c51be04@bsd64.grem.de> In-Reply-To: <50F9B6CC.3040303@infracaninophile.co.uk> References: <20130118035721.283135fb@bsd64.grem.de> <50F9B6CC.3040303@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 18 Jan 2013 20:55:40 +0000 Matthew Seaman <m.seaman@infracaninophile.co.uk> 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.). http://www.freebsd.org/cgi/query-pr.cgi?pr=175514 Assuming the code quality is sufficient, it would be great if it made it to base (not sure if des@freebsd.org 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 results. Cheers, Michael -- Michael Gmelin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130122193035.4c51be04>