Author Topic: Security fixes for Mozilla  (Read 4462 times)

André Heldoorn

  • Hero Member
  • *****
  • Thank You
  • -Given: 119
  • -Receive: 19
  • Posts: 787
    • View Profile
Re: Security fixes for Mozilla
« Reply #30 on: July 22, 2019, 03:51:55 am »
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

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 149
  • Posts: 2146
    • View Profile
Re: Security fixes for Mozilla
« Reply #31 on: July 22, 2019, 08:00:08 am »
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

  • Hero Member
  • *****
  • Thank You
  • -Given: 119
  • -Receive: 19
  • Posts: 787
    • View Profile
Re: Security fixes for Mozilla
« Reply #32 on: July 22, 2019, 08:14:45 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"

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

  • Hero Member
  • *****
  • Thank You
  • -Given: 119
  • -Receive: 19
  • Posts: 787
    • View Profile
Re: Security fixes for Mozilla
« Reply #33 on: July 22, 2019, 08:34:11 am »
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

  • Jr. Member
  • **
  • Thank You
  • -Given: 18
  • -Receive: 7
  • Posts: 99
    • View Profile
Re: Security fixes for Mozilla
« Reply #34 on: July 22, 2019, 09:44:01 am »
I tested your version and I can verify that it works well.
Will you continue to integrate more features from TenFourFox?


Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 149
  • Posts: 2146
    • View Profile
Re: Security fixes for Mozilla
« Reply #35 on: July 23, 2019, 02:23:12 am »
I tested your version and I can verify that it works well.
Will you continue to integrate more features from TenFourFox?

I'll likely get back to it when I get bored.

Jochen Schäfer

  • Jr. Member
  • **
  • Thank You
  • -Given: 18
  • -Receive: 7
  • Posts: 99
    • View Profile
Re: Security fixes for Mozilla
« Reply #36 on: July 23, 2019, 11:54:17 am »
Can we help?

Dariusz Piatkowski

  • Hero Member
  • *****
  • Thank You
  • -Given: 13
  • -Receive: 10
  • Posts: 585
    • View Profile
Re: Security fixes for Mozilla
« Reply #37 on: August 23, 2019, 05:19:32 pm »
Dave,

Just a bit of FYI type feedback re: the Pentium_m vs i686 builds.

By far, the i686 build works the best here. The Pentium_m seems to have a very short "lifespan", LOL, meaning that within a day of use I get to that magic 1Gig ram use at which point in time the browser basicly slows down to a crawl on literally any sites - do not even have to be complex - just takes forever to paint. A re-start fixes that but the lifespan becomes shorter and shorter to a point where after about 2-3 such re-starts the browser just permanently goes into this slow mode.

Meanwhile, the i686 build seems to chug along nicely. Yes, there is a bit of a perceived slow-down, but it appears to be on-par with the Phenom II build you did a while back. That build did seem faster overall, pages painted faster, the browser windows would open up faster, etc. but things like YouTube playback were always a problem.

Thank you again for getting this built and published!