Re: QuickJS and maintenance

[Adam Thompson <arthompson1990@gmail.com>]

On Wed, Feb 08, 2023 at 05:33:03AM -0500, Karl Dahlke wrote:
> I don't understand why there would be security concerns with quickjs. It is
> a language interpreter. It either works or it doesn't. All the security
> concerns fall on edbrowse, which is already packaged in several distros.

To provide a little more context, whereas adding an additional interpreter
does create an additional package requiring security support, it is no more
than any other library as far as its integration with Edbrowse. We're a lot
less js-centric in terms of our browsing engine than other browsers and
Quickjs is a lot more of a pure interpreter than more browser-integrated js
engines, at least that's how it appears.

> There are very likely security issues with edbrowse, but we don't have the
> staff to track them down. A typical browser has hundreds of programmers
> supporting it, and it's plugins and such, we have a couple of volunteers.
> The README file says there are no warranties, if you use edbrowse it's on
> you. This is typical boiler plate disclaimer. In any case I doubt quickjs
> would be the problem.

As Karl says, the development of Edbrowse is carried out by an extremely
small team. That being said, I think it'd actually be nice to have some more
interest in the project from security researchers (and yes I'm aware I'm
probably signing the project up to more work).

> > seems that QuickJS is not the most actively maintained project.
> 
> Well, much more than duktape, which we used before. We had to drop duktape
> because it doesn't even support the es6 features of js, and emails to their
> maintainers went unanswered for months. In other words, duktape can't parse
> most of the js out there at this time.
> 
> It is feasible to switch to another.
> The connection to the engine is entirely encapsulated in jseng-quick.c.
> If we wanted to use v8, example, we would write a jseng-v8.c
> and change the makefile.
> That's what we did when switching from duktape to quick.

And from smjs to duktape. That decision was driven by the fact that smjs is
far too integrated with the Firefox ecosystem rather than being developed as
an embeddable library. The same used to also be true of v8 which appeared to
make various assumptions about how it was being plugged in and was a
complete pain to build. This may have changed now (a quick internet search shows it's got its own website and is talked about as a discrete library) but we'd have to be
somewhat careful when considering the maintainability of plugging in another
js engine even though the code aspects are certainly technically viable.

I also wonder if it's worth contacting the Quickjs maintainers if you have
concerns about security and ongoing maintenance?

Cheers,
Adam.