On Thu, 2012-03-15 at 15:41 -0400, James Antill wrote: > Do we really need a daemon? Can't you have libproxy start some > sandboxed thing? > This isn't like a web browser where we'll constantly need to look for > proxies for URLs.
The dæmon is used by yum, the web browser, and everything *else* that ever wants to make an HTTP connection. It's not *just* for yum/urlgrabber. Yes, we need a dæmon. It's a much better approach to the problem than the original libproxy which reloads the PAC file in a JavaScript interpreter in *every* process that needs an answer. > > I'd be content just to put the DBus calls directly into yum/urlgrabber > > instead, but libproxy is an API that others are using and it seemed like > > the better choice in general when 'fixing' applications. But for yum, > > given the security environment, I'd be content to say "we *really* don't > > want to use the original libproxy, and PacRunner support is enough". > > Putting direct dbus calls into urlgrabber will get NAKd pretty quick, > by me. Worst case use the "libproxy API" and have some test that only > passes when using "PacRunner" as the backend for the API. So far, we don't have a simple way to 'detect' that the libproxy you happen to be running against today is calling PacRunner. And there's a module for the "real" libproxy that can get its answer from PacRunner too, so even then it doesn't have the security problems you were concerned about. But I'll see if I can come up with a suitable test for this. TBH, I'd be inclined to settle for a distribution-based default, where distributions that use PacRunner can *enable* it, while those who use "legacy" libproxy can leave it disabled. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Yum-devel mailing list [email protected] http://lists.baseurl.org/mailman/listinfo/yum-devel
