2008/1/25, Dan Fandrich wrote:

> We had a discussion here a month ago regarding the libproxy project and
> its integration with curl. I suspect the arguments made there will be
> very applicable to pacparser.

And I would also like to mention the security risk that _any_ app
using PAC proxy auto-config files incur.

PAC files aren't just plain old style configuration files, PAC files
incorporate javascript code to the concept of configuration file. PAC
files include at least one javascript function "FindProxyForURL(url,
host)" that will be executed at the system running the host app which
uses the PAC file which can reside on the same host or a remote one.

'Properly' crafted PAC files will allow remote and local execution of
arbitrary code by any app that uses PAC files.

Leave PAC files for web bowsers, they are already insecure.

I'm quite biased against incorporating into libcurl or curl tool code
base any additional 'mechanism' that makes it much easier to allow
code injection or external code execution once compiled.

Bindings are another world, and its up to each binding maintainer what
they do and provide.

Some rhetorical questions...

lib/curl code percentage relative to authentication/validation and
secure transports and protocols ?

Change in the rate/number of downloads since incorporation of SFTP and SCP ?

What sense makes having built in all the security mechanisms now
supported If afterwards we also incorporate others that allow
circumventing them ?

Why do we bother plugging memory leaks and potential buffer overflows ?

-- 
-=[Yang]=-