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. It would help me understand the issues if you could expand on your trust and signing concerns. >> 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. :-/ 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. > 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? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
