[systemd-devel] [RFC 3/6] proxy-discoveryd: Add PAC support through duktape js engine

[Marcel Holtmann]

Hi Zbyszek,

>>>>>> --- a/Makefile.am
>>>>>> +++ b/Makefile.am
>>>>>> @@ -5895,12 +5895,19 @@ rootlibexec_PROGRAMS += \
>>>>>>       systemd-proxy-discoveryd
>>>>>> 
>>>>>> systemd_proxy_discoveryd_SOURCES = \
>>>>>> +       src/proxy-discovery/duktape.h \
>>>>>> +       src/proxy-discovery/duktape.c \
>>>>> These files are not included in the patch, how do you intend to ship them?
>>>> 
>>>> I figured this could be included as a separate commit, when it will
>>>> be time to commit proxy-discoveryd someday.
>>>> Those 2 files represent more than 2 megabytes, so I did not want to
>>>> flood the ml.
>>> duktape should not be embedded in systemd. It's a separate project,
>>> which gets updates and has a life of its own.
>>> 
>>> Preferably, duktape would be packaged by distributions and we would
>>> use it like any other external library. If that is not possible, we'll
>>> have to look for some other option, but only then. For example,
>>> git submodule is still better than embedding of a snapshot.
>> 
>> that is not how this actually works with duktape. The release versions are building a single duktape.[ch] that you can only find in the releases. Otherwise you have to stitch that manually. It is pretty much designed to be included into other project as a copy. That is why nobody has actually packages this so far.
>> 
>> So while I get that including copies of other libraries is generally bad for security update reasons, but this one would qualify as an exception. It is just that we have to monitor duktape upstream releases and with that also update the duktape version in systemd.
>> 
>> It is something that is not the greatest solution, but something that is feasible. Keep in mind that embedding your JS engine right into your application allows for optimizations that you really want. We have build PACrunner against V8 and MozJS and these are two really painful experiences. For anybody wanting to build a small system, dealing with these two upstream packages is a nightmare. It sort of works in a large distribution like Fedora, but anything small it is not an option.
> 
> I know that embedding is the way that upstream suggests. But it is a
> bad fit for the way that systemd is distributed. Our primary consumers
> are distributions, and the first thing most distributions will do is
> to rip out the embedded copy in order to use a shared one. Something
> as big as a javascript engine is bound to have security updates and by
> embedding it systemd we would be forced to a) follow upstream changes,
> b) release systemd updates based on duktape releases. Not something that
> we want to do or would do very well.
> 
> We really should try to base this on a javascript engine which
> provides a shared library.

so do you know of a small Javascript engine with a proper license then? And that also has no additional dependencies.

I was not kidding when I said the V8 and MozJS are a nightmare when you want to build a small system. So these two are pretty much out of the question for the PAC service.

Regards

Marcel