From owner-freebsd-ports@FreeBSD.ORG Tue Jan 22 18:30:37 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1487B8D3 for ; Tue, 22 Jan 2013 18:30:37 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id 7BEDBB91 for ; Tue, 22 Jan 2013 18:30:35 +0000 (UTC) Received: (qmail 74045 invoked by uid 89); 22 Jan 2013 18:30:35 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@194.97.158.66) by mail.grem.de with ESMTPA; 22 Jan 2013 18:30:35 -0000 Date: Tue, 22 Jan 2013 19:30:35 +0100 From: Michael Gmelin To: Matthew Seaman 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> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:30:37 -0000 On Fri, 18 Jan 2013 20:55:40 +0000 Matthew Seaman 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