On 2017-03-24 2:45 PM, Bill McCloskey 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.
Yeah, I agree. 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!). 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. > On Fri, Mar 24, 2017 at 6:20 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com > <mailto: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 <mailto:ehsan.akhg...@gmail.com>> wrote: > >> On Wed, Mar 22, 2017 at 11:50 AM, Jeff Muizelaar > <jmuizel...@mozilla.com <mailto:jmuizel...@mozilla.com>> > >> wrote: > >>> > >>> On Wed, Mar 22, 2017 at 11:08 AM, Henri Sivonen > <hsivo...@hsivonen.fi <mailto: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 <http://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
