Using bidirectional authentication in pkgng

[Baptiste Daroussin]

On Tue, Jan 22, 2013 at 07:30:35PM +0100, Michael Gmelin wrote:
> On Fri, 18 Jan 2013 20:55:40 +0000
> Matthew Seaman <m.seaman at 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 at freebsd.org is still taking care of libfetch). 

Yes he is, that is why I have CCed him
> 
> 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
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20130123/2abaabab/attachment.sig>