edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Adam Thompson <arthompson1990@gmail.com>
To: Karl Dahlke <eklhad@comcast.net>
Cc: edbrowse-dev@edbrowse.org
Subject: Re: QuickJS and maintenance
Date: Thu, 9 Feb 2023 08:13:04 +0000	[thread overview]
Message-ID: <Y+SrEMt0b+KGuevm@pinebook-pro> (raw)
In-Reply-To: <20230108053303.eklhad@comcast.net>

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?


  reply	other threads:[~2023-02-09  8:13 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
2023-02-09  8:13   ` Adam Thompson [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+SrEMt0b+KGuevm@pinebook-pro \
    --to=arthompson1990@gmail.com \
    --cc=edbrowse-dev@edbrowse.org \
    --cc=eklhad@comcast.net \


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