On Tue, Mar 13, 2012 at 12:59:41PM +1300, Tim Foster wrote: > On the server-side, we'll add a new "proxied-urls" list property to > each existing "publishers" entry returned by the publisher/0/ > response. > > The list contains a series of [uri, proxy] lists so that clients > using -p can discover a suggested proxy to use automatically[1] > Older clients ignore the "proxied-urls" list, so I don't think this > needs a bump of the publisher/ response version. > > That property name is intentionally the same as the existing > "proxied-urls" list served by the syspub/0/ response, and I intend > to modify that to use special [uri, "syspub"] values, rather than > just the [uri, uri, ... ] values used today, indicating that the > system publisher proxy should be used.
I don't have a problem with this for the system publisher, but in any other situation I don't agree with letting the server specify the proxy for the client. First, how would the client contact the server if it didn't already know the proxy configuration? Second, the publisher may be in a faraway place, and unable to make a good generalization about configuration for the clients. Third, this would seem to setup a very simple man-in-the-middle attack. IMO, this should be configured on the client side for non system publishers. > On the client-side, when we discover that a URI is associated with a > proxy, we pass that proxy information to the transport (support for > passing a proxy already exists with the work that was done for the > system publisher) > > To support granular proxies from command line, we'll add a --proxy > option to "pkg set-publisher", which, when used with any "-g" or > "-m" URIs, associates that proxy with those URIs and overrides any > proxy configuration supplied from the server. A few questions about this. Should users environment variables override this setting? Currently libcurl honors the environment variables unless the CURLOPT_PROXY is set. In that case, the proxy option takes precedence. The current code will not proxy requests to localhost unless CURLOPT_PROXY is set. Do you expect customers to have a longer list of hosts not to proxy? Have you thought about how you want to manage this? Do you plan on supporting authentication to the proxy? Users can specify a username and password in the proxy string, but if we want that to be more secure, you'll have to figure out how to store the credentials safely and then use CURLOPT_PROXYUSERPWD or CURLOPT_PROXYUSER and CURLOPT_PROXYPASSWORD. What types of proxies do you plan to support? Curl lets you choose multiple types. There's an option to do this, but in 7.21.7, you can specify the type in the URL instead. Have you thought about how you want to make this visibile to the user? Should we upgrade libcurl >= 7.21.7? > Finally, the "pkg/system-repository" and "pkg/mirror" SMF services > will be modified to automatically proxy requests through the correct > proxy URI, as configured in the image from which they derive their > configuration. Right now, the services have a single > "config/http[s]_proxy" property set on the SMF instance that applies > to all URIs - I'd propose to have that override the --proxy settings > in the image from which each SMF service gains its configuration. The idea here is that pkg will be setting properties in the SMF service's instance? -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
