On Tue, Apr 25, 2017 at 9:02 PM, Bill McCloskey <wmcclos...@mozilla.com> wrote: > On Tue, Apr 25, 2017 at 5:41 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: >> >> What problem did you mean to address by code signing? > > The reason I suggested code signing is because loading libvoikko would > provide an easy way for people to inject code into Firefox. For a while > we've been trying to make it difficult for semi-legit-but-not-quite-malware > parties to load crappy code into Firefox (I'm thinking of crappy antivirus > software, adware, etc.). Removing binary XPCOM components and NPAPI support, > and requiring add-on signing, are all facets of this. If we simply load and > run code from any file named voikko.dll on the user's computer, then we've > opened up another door. It's a less powerful door since we probably (I hope) > wouldn't give them access to XPCOM. But they could still open windows that > look like they came from Firefox and I imagine there's other bad stuff I > haven't thought of. > > People often object to this argument by saying that, without libvoikko, > these bad actors could just replace libxul or something. But I think in > practice it would be harder for them to pull that off, both technically and > socially. From a technical perspective, it's harder to replace core parts of > Firefox while still leaving it in a working state, especially if the updater > is still allowed to run. And socially, I think it makes their software look > a lot more like malware if they replace parts of Firefox rather than simply > install a new DLL that we then load.
This concern applies to Windows but not to Linux, right? What about Mac? To address that concern, the local system itself would have to be treated as semi-hostile and the signature would have to be checked at library load time as opposed to the usual library install time. Do we have pre-existing code for that? AFAIK, in the case of OpenH264 we check a hash at library install time, but when we subsequently load the library, we don't check a hash or signature. In the case of OpenH264, the library gets loaded into a sandbox, which probably addresses the concern of a replacement OpenH264 with dodgy additional code being able to open windows that look like they came from Firefox. Assuming that we don't already have code for validating library provenance at library load time, wouldn't it make more sense to put effort into reusing the facilities for spawning a GMP process to spawn a low-privilege spell checking process than to try validate the provenance of already-installed code in a way that still doesn't address the crash impact concern in the case of the code being legitimate? > Overall, though, I agree with Ehsan that this discussion isn't very > worthwhile unless we what the voikko people want to do. It seems to me that this thread raises enough concerns on our side that it doesn't make sense to ask a third party what they want to do before we have an idea what we'd be OK with. Suppose they'd say they'd want to include libvoikko in Firefox like Hunspell? We'd have binary size and crash impact concerns. Suppose they'd say they'd want to make libvoikko download on-demand using Mozilla infra like OpenH264? We'd have concerns of finding release engineers and front end engineers with time to set it up, the crash impact concern and the concern of another party dropping malware in libvoikko's place. Suppose they'd say they'd want to install libvoikko somewhere on the user's library path and have us dlopen() it? We'd have concerns about crash impact, being able to remedy crashes, directing people to install non-Mozilla software (though @firefox on Twitter regularly does) and other parties dropping malware in libvoikko's place. Suppose they'd say they'd want to ship a back end for system spell checking frameworks and have us use the system spell checking API[1]? We'd have concerns of Windows 7 not being covered, directing people to install non-Mozilla software and crash impact at least in the Linux case (AFAICT, Enchant doesn't provide process isolation from the back end; I *think* Apple's solution does; not sure about Windows 8+) and having to write 3 system-specific spell checking integrations. Suppose they'd say they'd want to ship it as Web Assembly in a Web Extension? We'd have concern about allocating engineering time to enable a Web Extension to act as a spell checking provider, when there's only one extension that'd foreseeably use it. - - [1] Enchant on Linux (currently hard-codes the assumption that Voikko is Finnish only, so at least for the time being (until a potential future version of Enchant without that hard-coding makes its way through the distros) would throw Greenlandic, Sami and hope of other languages under the bus). https://bugzilla.mozilla.org/show_bug.cgi?id=422399 ISpellChecker on Windows 8+. The Windows built-in Finnish spell checker is competent, so there'd be no functional need for Voikko for Finnish. Would still need a non-Microsoft (i.e. libvoikko + hfst-ospell) spell checking provider for Greenlandic, Sami and potential other languages. https://bugzilla.mozilla.org/show_bug.cgi?id=741746 NSSpellChecker on Mac. The system spell checker for Finnish is bad compared to Voikko and the Windows build-in spell checker at least as of El Capitan. (My Mac doesn't run more recent macOS, so I can't immediately check if newer versions of macOS contain a competent Finnish spell checker.) However, a libvoikko-based back end is installable separately: http://verteksi.net/lab/osxspell/ . (Seems to be hard-coded to Finnish only at the moment.) https://bugzilla.mozilla.org/show_bug.cgi?id=86886 (System frameworks have the added benefit of sharing the user's personal dictionary across apps instead of Firefox being special and requiring the maintenance of a Firefox-specific personal dictionary.) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
