QuickJS and maintenance

QuickJS and maintenance

[Sebastian Humenda]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

Hi all

I have prepared a packaged version of QuickJS for Debian that is a dependency
of Edbrowse. However, during that process the question got raised whether such a
security-sensitive package would be appropriate to package in Debian. The main
point is that this puts additional burden on the Debian security team and it
seems that QuickJS is not the most actively maintained project.

Hard specific are the bindings of Edbrowse to QuickJS and is it feasible to
switch to something else? To me, Duktape comes to mind. It looks slightly more
maintained and is already in Debian.


Thanks
Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

QuickJS and maintenance

[Karl Dahlke]

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

Re: QuickJS and maintenance

[Adam Thompson]

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.

Re: QuickJS and maintenance

[Sebastian Humenda]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

Hi

Adam Thompson schrieb am 09.02.2023,  8:13 +0000:
>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.

Thanks for the context and your clarifications.

My intent has not been to enforce any decision or to criticise what is being
done. I know that the developer base of Edbrowse is small and I am working in
similar projects to know the maintenance burden of dependencies. This is
exactly why I brought this up: understanding the rationale behind the
decision. However, I still ask for a bit more understanding for the Debian
view, as the Security team needs to know about QuickJS (among more than 38000
other packages). QA is taken seriously, so my e-mail is just a step in that
process :-). I'll take your arguments to the security team and let's see where
it goes. It might well be that QuickJS is soon in Debian with the arguments
made.

Thanks
Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: QuickJS and maintenance

[Adam Thompson]

On Thu, Feb 09, 2023 at 10:48:00AM +0100, Sebastian Humenda wrote:
> Hi
> 
> Adam Thompson schrieb am 09.02.2023,  8:13 +0000:
> >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.
> 
> Thanks for the context and your clarifications.

No problem. As someone who uses Debian on a daily basis I've been wondering
how to facilitate a more up-to-date Edbrowse package for a while.

> My intent has not been to enforce any decision or to criticise what is being
> done. I know that the developer base of Edbrowse is small and I am working in
> similar projects to know the maintenance burden of dependencies. This is
> exactly why I brought this up: understanding the rationale behind the
> decision. However, I still ask for a bit more understanding for the Debian
> view, as the Security team needs to know about QuickJS (among more than 38000
> other packages). QA is taken seriously, so my e-mail is just a step in that
> process :-). I'll take your arguments to the security team and let's see where
> it goes. It might well be that QuickJS is soon in Debian with the arguments
> made.

Makes sense. Apologies if any of the remarks here came across as a lack of
understanding. I've been running Debian in various contexts for about 16
years now and am (at least from a user perspective) aware, and thankful for,
the large amount of work that goes into the distribution including on the
security front. Obviously consideration needs to be given when adding to
that.

That being said, to repeat what I said in my previous email, it's probably
worth contacting the Quickjs maintainers directly about these concerns as
they may be able to provide greater reassurance and assistance than we can.

Cheers,
Adam.

Re: QuickJS and maintenance

[Sebastian Humenda]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

Hi

[please don't CC me as I'm on the list]
Adam Thompson schrieb am 11.02.2023,  8:10 +0000:
>No problem. As someone who uses Debian on a daily basis I've been wondering
>how to facilitate a more up-to-date Edbrowse package for a while.

Have ou been thinking about stable or about the rolling release versions, i.e.
testing that didn't get updated in time? The a11y team is a bit understaffed.
Depending on how it goes with QuickJS, I could try to follow edbrowse
development along and update the packaging in time. However, for Debian
stable, I cannot make any promise for the time being, as this creates
additional effort -- but let's see. In any case, please feel free to drop in
#debian-a11y or ping me off-list if you need packaging updates.

>That being said, to repeat what I said in my previous email, it's probably
>worth contacting the Quickjs maintainers directly about these concerns as
>they may be able to provide greater reassurance and assistance than we can.

Agreed and on the To-Do-list.

Cheers
Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

QuickJS and maintenance

[Karl Dahlke]

If quickjs were packaged, we would need to change the makefile, as it 
currently assumes it has been built statically in parallel. 
In other words, we would simply link to it as we do with curl and 
readline etc. 
We might need an environment flag or parameter or something conditional 
in the makefile, 
to snag the library from it's standard place if it is there, or from a 
parallel directory if we had to build it. 
Then we should update the corresponding paragraph in README, on what is 
going on.

Karl Dahlke

Re: QuickJS and maintenance

[Sebastian Humenda]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

Hi

Karl Dahlke schrieb am 11.02.2023,  5:32 -0500:
>If quickjs were packaged, we would need to change the makefile, as it
>currently assumes it has been built statically in parallel. In other words,
>we would simply link to it as we do with curl and readline etc. We might need

Debian installs it to /usr/lib/quickjs/libquickjs.a, if that helps. Maybe you
were assuming that anyway.

Cheers
Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: QuickJS and maintenance

[Adam Thompson]

On Sun, Feb 12, 2023 at 08:39:22AM +0100, Sebastian Humenda wrote:
> Hi
> 
> Karl Dahlke schrieb am 11.02.2023,  5:32 -0500:
> >If quickjs were packaged, we would need to change the makefile, as it
> >currently assumes it has been built statically in parallel. In other words,
> >we would simply link to it as we do with curl and readline etc. We might need
> 
> Debian installs it to /usr/lib/quickjs/libquickjs.a, if that helps. Maybe you
> were assuming that anyway.

As long as we can find it via pkg-config we can just look for it, perhaps
using a flag of some sort to switch between that and providing a path to a
local build? That'd mean we didn't need to know where it'd be installed if we
were building using the system (read packaged) Quickjs whilst keeping the
ability to use a local version.