From: Karl Dahlke <eklhad@comcast.net>
To: edbrowse-dev@edbrowse.org
Subject: QuickJS and maintenance
Date: Wed, 08 Feb 2023 05:33:03 -0500 [thread overview]
Message-ID: <20230108053303.eklhad@comcast.net> (raw)
In-Reply-To: <Y+NsPuKApVhdHG2g@kraftkrust>
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
next prev parent reply other threads:[~2023-02-08 10:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-08 9:32 Sebastian Humenda
2023-02-08 10:33 ` Karl Dahlke [this message]
2023-02-09 8:13 ` Adam Thompson
2023-02-09 9:48 ` Sebastian Humenda
2023-02-11 8:10 ` Adam Thompson
2023-02-11 9:56 ` Sebastian Humenda
2023-02-11 10:32 ` Karl Dahlke
2023-02-12 7:39 ` Sebastian Humenda
2023-02-12 18:54 ` Adam Thompson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230108053303.eklhad@comcast.net \
--to=eklhad@comcast.net \
--cc=edbrowse-dev@edbrowse.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).