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.
-Bill On Fri, Mar 24, 2017 at 6:20 AM, 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 think it's better to engage the developers of those > libraries first and ask them how they would like us to proceed. At any > rate, something has to change on their side, since after Firefox 57 > presumably Firefox would just ignore their XPI file or something. The > actual implementation mechanism would probably end up being the > dlopening that you're suggesting, but if we're going to be signing up to > doing that, we better have at least a communication channel with the > authors of those libraries in case for example we need to change > something on our interface some day. > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
