On Fri, Mar 24, 2017 at 3:20 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > On 2017-03-24 4:20 AM, Henri Sivonen wrote: >> On Fri, Mar 24, 2017 at 2:38 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> >> wrote: >>> On Wed, Mar 22, 2017 at 11:50 AM, Jeff Muizelaar <jmuizel...@mozilla.com> >>> wrote: >>>> >>>> On Wed, Mar 22, 2017 at 11:08 AM, Henri Sivonen <hsivo...@hsivonen.fi> >>>> wrote: >>>>> >>>>> dlopening libvoikko, if installed, and having thin C++ glue code >>>>> in-tree seems much simpler, except maybe for sandboxing. What are the >>>>> sandboxing implications of dlopening a shared library that will want >>>>> to load its data files? >>>> >>>> My understanding is that the spell checker mostly lives in the Chrome >>>> process so it seems sandboxing won't be a problem. >>> >>> >>> That is mostly correct. The spell checker *completely* lives in the parent >>> process and is completely unaffected by sandboxing. >>> >>> But that's actually a problem. My understanding is that WebExtensions won't >>> be allowed to load code in the parent process. Bill, Kris, is that correct? >>> If yes, we should work with the maintainers of the Finnish and Greenlandic >>> dictionaries on adding custom support for loading their code... >> >> But when (according to doing a Google Web search excluding mozilla.org >> and wading through all the results and by searching the JS for all >> AMO-hosted extensions) the only out-of-tree spell checkers use >> libvoikko, why involve Web Extensions at all? Why wouldn't we dlopen >> libvoikko and put a thin C++ adapter between libvoikko's C API and our >> internal C++ interface in-tree? That would be significantly simpler >> than involving Web extensions. > > Is that different than what I suggested above in some way that I'm > missing?
I thought you meant that Web Extensions were your primary choice if they could load code into the parent process. > I think it's better to engage the developers of those > libraries first and ask them how they would like us to proceed. I wanted to get an understanding of what we'd be OK with before contacting Harri Pitkänen (libvoikko developer) or Timo Jyrinki (libvoikko and mozvoikko maintainer for Debian and Ubuntu), because I don't want to cause them to write code only to find a Mozilla decision render the code useless. On Fri, Mar 24, 2017 at 8:45 PM, Bill McCloskey <wmcclos...@mozilla.com> wrote: > If we do end up going with the dlopen plan, let's make sure that we enforce > some kind of code signing. We're finally almost rid of all the untrusted > binary code that we used to load (NPAPI, binary XPCOM, ctypes). It would be > a shame to open up a new path. What threat do you intend to defend against? On Linux, we should think of libvoikko as an optional system library. (If you install Ubuntu choosing English as the system language at install time, libvoikko is not installed by default. If you install Ubuntu choosing Finnish as the system language at install time, libvoikko is installed by default. In any case, you can get it from the distro repo.) We already dlopen() PulseAudio as a system library that we don't verify. In the Crash Reporter, we dlopen() libcurl and some Gnome stuff. I expect that someone operating with the user's privileges can cause whatever unverified code to be mapped into our address space via LD_PRELOAD and system libraries that we link against unconditionally. As for Windows, since a spell checker doesn't add Web-exposed functionality, we wouldn't have the risk that we had with NPAPI (or, technically, with arbitrary add-ons) that a site could entice users to run a random setup.exe in order to see some additional Web content. The libvoikko API is pretty narrow, so I wouldn't expect it to enable more anti-virus mischief than what can be done by hooking stuff into the Windows system DLLs that we need to use. The main problems I see are: 1) Right now the libvoikko distribution point is without https. (Fixable with Let's Encrypt.) 2) We couldn't trigger a libvoikko autoupdate on Windows/Mac if there was a crasher bug in the library. (I'd expect the distros to take care of pushing an update in the Linux case. It's the same situation with e.g. PulseAudio and Gtk anyway.) On Sat, Mar 25, 2017 at 8:48 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > Another option would be talking to the maintainers of libvoikko and > seeing if they would be open to maintaining the Mozilla bindings, in > which case I think we should even consider doing something like what we > do to download the OpenH264 binary at runtime when we need to. We could > even build and sign it in the infrastructure ourselves if we imported it > into the tree, with task cluster this is possible today with a super > simple shell script (well, at least the building side of it!). If we are willing to do the engineering for that, that would be great! (Of course, just putting libvoikko into libxul would be simpler, but would cost an added 250 KB in libxul size for everyone who doesn't need libvoikko.) The situation with the Tracking Protection data suggests that we are OK with GPLed run-time downloaded data files even though not code. Have I inferred the licensing position correctly? That is, if we distributed libvoikko under MPL 1.1, would we be OK with also distributing and autodownloading GPLed dictionary files? > We > basically need someone to sign up for maintaining it, since I doubt that > MoCo will prioritize supporting a whole new spell checking backend for 2 > new languages, but I think we can do a lot to help. I wouldn't expect MoCo to sign up to maintain libvoikko itself, but the glue code needed between mozISpellCheckingEngine and libvoikko is *extremely* thin: https://github.com/voikko/mozvoikko/blob/master/components/MozVoikko2.js (most of that code is jsctypes and XPCOM boilerplate; the code that would need to be rewritten in C++ is almost nothing except trivial forwarding to C.) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
