On 2017-04-18 2:38 AM, Henri Sivonen wrote: > On Sat, Apr 15, 2017 at 8:06 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: >> On 2017-03-27 3:30 AM, Henri Sivonen wrote: >>> 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.) >> >> It is also untrusted and unsigned code and can cause security and >> unstability issues. We have done a lot of work to remove all such code >> from our parent process. I don't think it's useful to make an analogy >> between this code and things like gtk. > > I get it that libvoikko and gtk may (I haven't checked) have a > different code quality level and, therefore, involve different parent > process crash or exploitability risk. However, on e.g. Ubuntu and > Debian the trust and signedness status is indeed the same as for gtk: > both gtk and libvoikko are distro-provided code that is signed for > delivery but signatures aren't checked when executing the code (i.e. > the trust model of the OS doesn't treat root-owned libraries under > /usr as adversarial in general) and the distro is responsible for > pushing updates in case of critical bugs.
Sure, but why do you keep bringing up these two distros? What about Windows, where presumably most of Finnish and Greenlandic speaking users will be? :-) > It would help me understand the issues if you could expand on your > trust and signing concerns. The security issues should be obvious. I don't trust the C++ code that I write and by extension I don't trust the C++ code that anybody else writes. The stability issues: If you go to https://crash-stats.mozilla.com/topcrashers/?product=Firefox&version=52.0.2&days=7 right now, you will see top crashers caused by untrusted binary code that we don't control doing bad things (I spotted #11, js::Proxy::construct based on a cursory look right now). We have years of concrete hard evidence in terms of 100s of crash bug reports. What's even worse about this particular case is that due to the smaller size of the user base, the chances of issues like crashes raising to an extent that they become visible under our radar is slim. So the concrete risk would be the possibility of loading this code in the parent process causing a startup crash that flies under the radar and costs us all users in those locales. >>> 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.) >> >> That's not an option. 250KB for essentially dead code for most of our >> users is too much. > > Annoyingly, chances are that no one will be willing to say ahead of > time how many kilobytes would be acceptable. :-/ Yup. :-( If you ask the Fennec, they'll rightly say 0 though. > As for how many users this would benefit, there's a big difference > between the immediate and the potential. The immediate is: very few > relative to the entire Firefox user population. There exist > dictionaries with clear licensing for Finnish, Northern Sami, Southern > Sami and Lule Sami and a dictionary with unclear (at least to me) > licensing for Greenlandic. The spell checking engine has broader > applicability, though. Maybe if we made it available with the same > ease as Hunspell, it would make it worthwhile for other languages that > are too complex for Hunspell to get dictionaries made or maybe some > languages that are unsatisfactorily supported by Hunspell would > migrate leading to better UX for users whose language already seems to > be covered by Hunspell but isn't actually handled well by Hunspell. > Hard to say. Don't get me wrong, I do think we definitely should not "drop" support for spell checking for those users which means we need to figure out a way to keep this working. We just need to figure out a plan that works well both for Gecko and mozvoikko. So please take all of my objections so far as purely technical, not at all objections to the idea of supporting mozvoikko. :-) (In fact, I'd usually take this work on myself given that I'm the closest person to the spell checker for the better or worse, but unfortunately these days due to the Quantum Flow stuff I really can't add anything to my plate...) >> It may still be possible for them to provide a native library to us that >> we can load on the background thread and call into but it may require >> code changes on their side as well as our side to get that to work properly. > > In a background thread in the chrome process? I.e. not isolated in a > way that would protect against the spell checker crashing the chrome > process? In a background thread in the chrome process, for now. But I'm very interested to see if one day we can move hunspell into its own little process based on this work to be isolated from any potential security bugs in it. One advantage of Gecko being in control of loading this library explicitly would be that we could make this all work seamlessly for the library, as in, when it moves from the parent process to the future spell checker process, the library should be blind to any changes! Of course this is assuming the library is OK with being called on a background thread (it will still only ever be access on a single thread so it won't need to be thread safe, it just doesn't need to be tied to any main thread assumptions, but I would be surprised for a spell checker engine to have any such assumptions... Hunspell definitely couldn't care less. :-) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
