* QuickJS and maintenance @ 2023-02-08 9:32 Sebastian Humenda 2023-02-08 10:33 ` Karl Dahlke 0 siblings, 1 reply; 9+ messages in thread From: Sebastian Humenda @ 2023-02-08 9:32 UTC (permalink / raw) To: edbrowse-dev [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* QuickJS and maintenance 2023-02-08 9:32 QuickJS and maintenance Sebastian Humenda @ 2023-02-08 10:33 ` Karl Dahlke 2023-02-09 8:13 ` Adam Thompson 0 siblings, 1 reply; 9+ messages in thread From: Karl Dahlke @ 2023-02-08 10:33 UTC (permalink / raw) To: edbrowse-dev 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: QuickJS and maintenance 2023-02-08 10:33 ` Karl Dahlke @ 2023-02-09 8:13 ` Adam Thompson 2023-02-09 9:48 ` Sebastian Humenda 0 siblings, 1 reply; 9+ messages in thread From: Adam Thompson @ 2023-02-09 8:13 UTC (permalink / raw) To: Karl Dahlke; +Cc: edbrowse-dev 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: QuickJS and maintenance 2023-02-09 8:13 ` Adam Thompson @ 2023-02-09 9:48 ` Sebastian Humenda 2023-02-11 8:10 ` Adam Thompson 0 siblings, 1 reply; 9+ messages in thread From: Sebastian Humenda @ 2023-02-09 9:48 UTC (permalink / raw) To: edbrowse-dev [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: QuickJS and maintenance 2023-02-09 9:48 ` Sebastian Humenda @ 2023-02-11 8:10 ` Adam Thompson 2023-02-11 9:56 ` Sebastian Humenda 0 siblings, 1 reply; 9+ messages in thread From: Adam Thompson @ 2023-02-11 8:10 UTC (permalink / raw) To: Sebastian Humenda; +Cc: edbrowse-dev 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: QuickJS and maintenance 2023-02-11 8:10 ` Adam Thompson @ 2023-02-11 9:56 ` Sebastian Humenda 2023-02-11 10:32 ` Karl Dahlke 0 siblings, 1 reply; 9+ messages in thread From: Sebastian Humenda @ 2023-02-11 9:56 UTC (permalink / raw) To: edbrowse-dev [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* QuickJS and maintenance 2023-02-11 9:56 ` Sebastian Humenda @ 2023-02-11 10:32 ` Karl Dahlke 2023-02-12 7:39 ` Sebastian Humenda 0 siblings, 1 reply; 9+ messages in thread From: Karl Dahlke @ 2023-02-11 10:32 UTC (permalink / raw) To: edbrowse-dev 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: QuickJS and maintenance 2023-02-11 10:32 ` Karl Dahlke @ 2023-02-12 7:39 ` Sebastian Humenda 2023-02-12 18:54 ` Adam Thompson 0 siblings, 1 reply; 9+ messages in thread From: Sebastian Humenda @ 2023-02-12 7:39 UTC (permalink / raw) To: edbrowse-dev [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: QuickJS and maintenance 2023-02-12 7:39 ` Sebastian Humenda @ 2023-02-12 18:54 ` Adam Thompson 0 siblings, 0 replies; 9+ messages in thread From: Adam Thompson @ 2023-02-12 18:54 UTC (permalink / raw) To: edbrowse-dev 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2023-02-12 18:54 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-02-08 9:32 QuickJS and maintenance Sebastian Humenda 2023-02-08 10:33 ` Karl Dahlke 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
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).