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.
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.
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.
Hope this helps.
Karl Dahlke
