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.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matt...@infracaninophile.co.uk
signature.asc
Description: OpenPGP digital signature
