OS/2, eCS & ArcaOS - Technical > Mail-News

Security fixes for Mozilla

<< < (7/8) > >>

André Heldoorn:
IIRC I restricted myself to the generic DLLs of e.g. "I also marked some of the supporting DLLs to load high, namely icudt.dll, icuin.dll, icuuc.dll, hunspell10.dll, libvpx4.dll as they used the most and seemed safe". Seemed safe was good enough for me.

Sometimes I wished I had recorded a list of DLLs required by which app, which would come down to such an utility indeed. A "PM DLL"-ish database for all *.DLL and *.EXE files newer than a specific date. So you can start marking files more safely (used by Mozilla only) or delete files which no longer are required (without e.g. keeping RPM data files in mind).

Recording which DLL files were installed for what reason is easier with a clean eCS boot drive policy, but those records would be based on a random install order of apps and missing DLLs. I know HUNSPEL0.DLL was a new requirement of Mozilla to me, but since that moment it's an assumption that no other app requires this installed, marked DLL. Hmm, compiling a full database wouldn't be that hard. Move DLLs, start the limited number of qualifying apps, restore and record missing DLLs per qualifying app. But then the problem is that I don't install all apps, so such a time-consuming database would only "work for me". Nevertheless it may be easier than writing an illusive utility.

Dave Yeo:
Yes, those seem safe. Libvpx4 may be used by some builds of FFmpeg but should be safe unless it breaks OW compiled SDL. As far as I know, hunspell is only used by Firefox but will be used for more in the future as Chrome and LibreOffice use it. Those should handle DLLs loaded high fine anyways. I chose to keep using the intree versions of Hunspell for SM and TB. I like the Mozilla dictionaries.
You could use Theseus to see which DLLs are loaded, and by starting various programs, see the changes. Even then some DLLs that are dynamically loaded might not show up until needed. DIVE for example is only loaded by Cairo when it will be used, which depends on video driver and such.

André Heldoorn:

--- Quote from: André Heldoorn on July 22, 2019, 03:51:55 am ---"I also marked some of the supporting DLLs to load high, namely icudt.dll, icuin.dll, icuuc.dll, hunspell10.dll, libvpx4.dll as they used the most and seemed safe"
--- End quote ---

Verified: that was my source. The distributed file OtherDLLs.ZIP only marks those "generic" third-party DLLs as high.

A main technical difference, compared with its InsTurbo.EXE starting point, is that OtherDLLs.CMD uses a Rexx DLL. Then the user has to check less output, like a "rc=5". And first it tries to unlock the DLL and tries to make sure that only the parameter "-c" is in active use afterwards, without an overload of output of any supported external utility.

André Heldoorn:
FTR: Hunspell may be as good as it gets. But back then I already had a Mozilla SM/TB dictionary, and I was only installing missing, minimal technical requirements of a new release of SM. HUNSPEL0.DLL was the only requirement of the Hunspell package, without requiring other Hunspell (data) files. Hence just an installed HUNSPEL0.DLL, without having to figure out where to save all other Hunspell files.

Here no RPM, no Unix directory structures, and a clean boot drive policy, so I never gave Hunspell a real and honest try.

Jochen Schäfer:
I tested your version and I can verify that it works well.
Will you continue to integrate more features from TenFourFox?


[0] Message Index

[#] Next page

[*] Previous page

Go to full version