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

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Mon Apr 13 10:10:54 PDT 2015


On Mon, Apr 13, 2015 at 09:51:05AM -0700, Marcel Holtmann wrote:
> 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.

No, but I don't think this can be the guiding principle here. We
already have dependencies on a large number of things: gnutls,
docbook, unifont, libmicrohttpd, python, and a bunch of smaller
libraries. I know that another dependency might be difficult for
embedded systems, but a "small" library might actually be more work to
maintain the long run than bigger library which is easier to integrate.

> 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.

I certainly can believe that ;)

Zbyszek


More information about the systemd-devel mailing list