OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Mail-News => Topic started by: Dave Yeo on April 14, 2019, 02:30:10 am

Title: Security fixes for Mozilla
Post by: Dave Yeo on April 14, 2019, 02:30:10 am
I've been experimenting with porting security fixes from tenfourfox, a Firefox fork for PowerPC Macs that was also forked from 45ESR. Currently at about 50 changesets, over a 100 security issues patched I believe. For testing I've uploaded,
https://bitbucket.org/dryeo/mozilla-os2/downloads/firefox-45.9.0.en-US.os2-Pentium-m-SUa1.zip (https://bitbucket.org/dryeo/mozilla-os2/downloads/firefox-45.9.0.en-US.os2-Pentium-m-SUa1.zip) which also has unofficial branding instead of nightly.
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/thunderbird-45.8.0.en-US.os2-Pentium-m-SUa1.zip (https://bitbucket.org/dryeo/dry-comm-esr31/downloads/thunderbird-45.8.0.en-US.os2-Pentium-m-SUa1.zip) and
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9esr.en-US.os2-Pentium-M-SUa1.zip (https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9esr.en-US.os2-Pentium-M-SUa1.zip)

Don't forget to turn off mozturbo before updating and marking DLLs to load high. Should only use the latest release RPM's
Title: Re: Security fixes for Mozilla
Post by: Doug Clark on April 15, 2019, 01:18:19 am
Thanks Dave,

Please remind me how to mark DLLs to load high.
Title: Re: Security fixes for Mozilla
Post by: Dave Yeo on April 15, 2019, 01:34:05 am
Install the highmem package with Yum or ANPM. then in your program directory, after stopping ffturbo (ffturbo -u),
Code: [Select]
highmem -c *.dll then restart ffturbo or reboot.
Title: Re: Security fixes for Mozilla
Post by: Doug Clark on April 15, 2019, 04:04:12 am
Thanks.

Very nice. I notice this version does not have the pesky "It looks like you haven't started Firefox in a while" message at the bottom. Thanks for your work on this.
Title: Re: Security fixes for Mozilla
Post by: David McKenna on April 15, 2019, 11:46:48 pm
 Thanks Dave! SeaMonkey working great here....
Title: Re: Security fixes for Mozilla
Post by: Neil Waldhauer on April 17, 2019, 03:39:22 pm
This is regarding the 4/4 version of Firefox. I'll get up to testing the more recent build shortly.

Firefox does not seem to start by itself. If I put firefox into Internet Application Integration so that I can launch web URL objects, or open a web page from Thunderbird, that does not work until I install Run!

The bitwise port starts without any help from Run!
Title: Re: Security fixes for Mozilla
Post by: Dave Yeo on April 18, 2019, 04:03:46 am
This is regarding the 4/4 version of Firefox. I'll get up to testing the more recent build shortly.

Firefox does not seem to start by itself. If I put firefox into Internet Application Integration so that I can launch web URL objects, or open a web page from Thunderbird, that does not work until I install Run!

The bitwise port starts without any help from Run!

Strange. I just used IAI to make Firefox (one I just built using the full path to it) the default web browser application and opening a web page from Thunderbird changed to Firefox from the previous SeaMonkey as expected.
Clicking on a web URL object such as blonde guy still opened SeaMonkey, opening the properties, showed under Browser, D:\Programs\seamonkey\seamonkey!lk.exe which is why it kept using SeaMonkey, without the --no-remote parameter, the browser, even the older SM, just opens a new window in the running browser. I assume if I did not have SM already running, it would have opened the older browser that the URL object points to.
Not the best way to set things up in my opinion and likely the reason that IAI doesn't seem to work for the system installed URL objects.
Thunderbird, I'm not sure about though there was an issue on the Arca issue tracker where some one had a similar problem with the Bitwise build of Firefox, he finally worked around the issue by setting up Thunderbird to use Firefox directly.
There's no code changes between the Bitwise build and the one you're using.
Title: Re: Security fixes for Mozilla
Post by: Dariusz Piatkowski on April 19, 2019, 02:34:53 am
Hey Dave!

I've been experimenting with porting security fixes from tenfourfox, a Firefox fork for PowerPC Macs that was also forked from 45ESR. Currently at about 50 changesets, over a 100 security issues patched I believe. For testing I've uploaded,
https://bitbucket.org/dryeo/mozilla-os2/downloads/firefox-45.9.0.en-US.os2-Pentium-m-SUa1.zip (https://bitbucket.org/dryeo/mozilla-os2/downloads/firefox-45.9.0.en-US.os2-Pentium-m-SUa1.zip) which also has unofficial branding instead of nightly...

So I wanted to give this drop a whirl, unpacking to a clean dir and attempting to run produced the following trap:

Code: [Select]
______________________________________________________________________
 Exception Report - created 2019/04/18 20:24:54
______________________________________________________________________
 OS2/eCS Version:  2.45
 # of Processors:  5
 Physical Memory:  3327 mb
 Virt Addr Limit:  2560 mb
 Exceptq Version:  7.11.3-shl (Jul  5 2016)
______________________________________________________________________
 Exception C0000005 - Access Violation
______________________________________________________________________
 Process:  G:\APPS\TCPIP\FIREFOX\FIREFOX.EXE (04/13/2019 15:32:15 282,117)
 PID:      144 (324)
 TID:      01 (1)
 Slot:     AB (171)
 Priority: 200

 Module:   N/A
 Filename: N/A
 Cause:    Invalid execution address 00020CBE
______________________________________________________________________
 Registers
______________________________________________________________________
 EAX : 00000008   EBX  : 0019F844   ECX : 00000002   EDX  : 0019FF4C
 ESI : 0019F948   EDI  : 18A68C54
 ESP : 0019F820   EBP  : 0019FA4C   EIP : 00020CBE   EFLG : 00010206
 CS  : 005B       CSLIM: FFFFFFFF   SS  : 0053       SSLIM: FFFFFFFF

 EAX : not a valid address
 EBX : read/write memory on this thread's stack
 ECX : not a valid address
 EDX : read/write memory on this thread's stack
 ESI : read/write memory on this thread's stack
 EDI : read/write memory at 0003:00008C54 in LIBCN0
______________________________________________________________________
 Stack Info for Thread 01
______________________________________________________________________
   Size       Base        ESP         Max         Top
 00100000   001A0000 -> 0019F820 -> 0018F000 -> 000A0000
______________________________________________________________________
 Call Stack
______________________________________________________________________
   EBP     Address    Module     Obj:Offset    Nearest Public Symbol
 --------  ---------  --------  -------------  -----------------------
 Trap  ->  00020CBE   Invalid address: 00020CBE

I've attached the full trp file below.

Did not re-boot, but the ffturbo was killed and no DLL remainder in memory.
Title: Re: Security fixes for Mozilla
Post by: Dariusz Piatkowski on April 19, 2019, 02:55:21 am
Well, a re-boot later (probably should have done that to start off with, just to be sure) the browser does come up, but traps on the very last steps of loading any sites (tried several, including this forum).

Dave, I want to say this is very similar to something we hit when you built the AMD PhenomII version...does that ring any bells for you?
Title: Re: Security fixes for Mozilla
Post by: Dave Yeo on April 19, 2019, 05:35:59 am
It's a crash that is usually triggered by badly written web sites, I found one through a bug that produced very similar trps the other day. Why it is happening consistently for you I don't know. Have you tried safe mode and/or a new profile? Hopefully that first trp, which I've never seen the like of, didn't screw something in your profile. Always a good idea to back up the profile before experimenting, something I should stress more.
Title: Re: Security fixes for Mozilla
Post by: Dave Yeo on May 08, 2019, 04:40:55 am
Well, a re-boot later (probably should have done that to start off with, just to be sure) the browser does come up, but traps on the very last steps of loading any sites (tried several, including this forum).

Dave, I want to say this is very similar to something we hit when you built the AMD PhenomII version...does that ring any bells for you?

Had a similar trp, reproducible on certain sites, with the SUa1 builds, now fixed for SUa2.
Title: Re: Security fixes for Mozilla
Post by: Dave Yeo on June 05, 2019, 04:49:16 am
As some have noticed, I've uploaded the SUa2 builds, both i686 and Pentium-m builds of Firefox (nightly), SeaMonkey and Thunderbird, all on my Bitbucket pages.
Fixed the crash that some web pages triggered. Fixed loading the Amtrak web site.
Added a bunch of security certificates and pins, bring it to the same level as the last release of 52ESR, this meant re-adding the NSS and NSPR libraries as updating the RPMs broke Firefox 38 etc.
Due to this there is also a new release of mozturbo which also includes a script to mark the DLLs and create program objects, thanks to André Heldoorn for the script. Also some icons, thanks to David Graser. The icons have to be associated manually for now.
Title: Re: Security fixes for Mozilla
Post by: Pete on June 05, 2019, 03:41:56 pm
Hi Dave

As some have noticed, I've uploaded the SUa2 builds, both i686 and Pentium-m builds of Firefox (nightly), SeaMonkey and Thunderbird, all on my Bitbucket pages.


All I see at https://bitbucket.org/dryeo/mozilla-os2/downloads/ are firefox and ffmpeg packages. Am I looking at the correct url?


Regards

Pete
Title: Re: Security fixes for Mozilla
Post by: Dave Yeo on June 05, 2019, 04:34:41 pm
https://bitbucket.org/dryeo/mozilla-os2/downloads/firefox-45.9.0.en-US.os2-Pentium-m-SUa2.zip (https://bitbucket.org/dryeo/mozilla-os2/downloads/firefox-45.9.0.en-US.os2-Pentium-m-SUa2.zip) They're packaged as Firefox but have the nightly theme.
Title: Re: Security fixes for Mozilla
Post by: Eugene Tucker on June 05, 2019, 04:37:19 pm
Is the Mozturbo new version released yet?
Title: Re: Security fixes for Mozilla
Post by: Dave Yeo on June 05, 2019, 04:57:33 pm
Is the Mozturbo new version released yet?

https://bitbucket.org/dryeo/mozturbo/downloads/mozturbo-v0.7.zip (https://bitbucket.org/dryeo/mozturbo/downloads/mozturbo-v0.7.zip)
They'll likely be a v0.8 soon, but it will just have installer/icon tweeks.
Title: Re: Security fixes for Mozilla
Post by: ivan on June 05, 2019, 06:14:16 pm
Hi Dave,

Thanks for your effort.  One question though, which firefox should I use with AMD Ryzen processor?  I have found that firefox 60.7.0esr works extremely well on my Linux Mint Ryzen computer.
Title: Re: Security fixes for Mozilla
Post by: xynixme on June 05, 2019, 09:10:06 pm
All I see at https://bitbucket.org/dryeo/mozilla-os2/downloads/ are firefox and ffmpeg packages. Am I looking at the correct url?
MozTurbo and SM/TB can be found in different directories indeed:

https://bitbucket.org/dryeo/mozturbo/downloads/
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/
Title: Re: Security fixes for Mozilla
Post by: Dave Yeo on June 06, 2019, 01:28:00 am
Hi Dave,

Thanks for your effort.  One question though, which firefox should I use with AMD Ryzen processor?  I have found that firefox 60.7.0esr works extremely well on my Linux Mint Ryzen computer.

The Pentium M should be best for most everyone, with the i686 for those without SSE2 capable processors.
After 52ESR, Mozilla targets the Pentium M as well, so your 60.7.0 should be similar for targeting.
Title: Re: Security fixes for Mozilla
Post by: Dariusz Piatkowski on July 21, 2019, 02:17:50 pm
Hi Dave!

https://bitbucket.org/dryeo/mozilla-os2/downloads/firefox-45.9.0.en-US.os2-Pentium-m-SUa2.zip (https://bitbucket.org/dryeo/mozilla-os2/downloads/firefox-45.9.0.en-US.os2-Pentium-m-SUa2.zip) They're packaged as Firefox but have the nightly theme.

Thank you again for keeping up with these things.

Alright, so I replaced the AMD Phenom II version you did for me with this SU2 Pentium-m drop, the CPU usage is visibly more spikey, yet the browser actually appears more responsive after prolonged usage, which is ultimately a good thing as that brings stability.

I do have a question regarding the DLLs you included in your distro, and I'm not talking the standard XUL.DLL stuff, but the remaining DLLs which are also available through the RPM package install, they are:

Code: [Select]
Directory of G:\apps\tcpip\firefox

 5-04-19   2:03a    228225           0  freebl3.dll
 5-04-19  12:34a    137493           0  nspr4.dll
 5-04-19   2:04a    500726           0  nss3.dll
 5-04-19   2:04a    270578           0  nssckbi.dll
 5-04-19   2:03a     72331           0  nssdbm3.dll
 5-04-19   2:03a     74803           0  nssutil3.dll
 5-04-19  12:34a     12300           0  plc4.dll
 5-04-19  12:34a     10733           0  plds4.dll
 5-04-19   2:04a     74081           0  smime3.dll
 5-04-19   2:03a    110309           0  softokn3.dll
 5-04-19   2:04a    117247           0  ssl3.dll

What's the best approach to managing these? And by that I mean: do I replaced the previously installed RPM package DLLs with your versions, or do I leave them in the Firefox install directory, but if I do, will they conflict with any other apps that will of course pull them from the RPM install (that being \usr\lib...)?

In comparison to the Phenom II build, these DLLs were included in that release, so I continued to use the RPM package ones.
Title: Re: Security fixes for Mozilla
Post by: xynixme on July 21, 2019, 04:13:05 pm
What's the best approach to managing these?
Despite of disk full-error, here each installed member of the non-legacy Mozilla family now has its own copy of those FF/SM/TB DLLs. No RPM, so no RPM to accidently unmark DLLs marked to use memory > 512 MiB. I'm pretty sure moving the DLLs did make sense, and I would be overdoing it when I'd move those DLLs to a LIBPATH directory. And I don't have to delete all duplicate DLLs after each update.

InsTurbo should support both setups, with or without optionally (ab)using BEGINLIBPATH in case you've got several installed copies of DLLs.
Title: Re: Security fixes for Mozilla
Post by: Dave Yeo on July 21, 2019, 05:57:50 pm
Hi Dariusz, just keep them in their directories. FF etc set BEGINLIBPATHSTRICT and LIBPATHSTRICT so there shouldn't be any conflicts. I did it this way as the certificates have been updated and it was easier to use the intree NSS and it depends on NSPR.
As André  says, the latest mozturbo supports the extra DLLs and he wrote a script to make use easier.
I got sick of working on Mozilla and have been taking a break from it.
Title: Re: Security fixes for Mozilla
Post by: Dariusz Piatkowski on July 21, 2019, 06:45:00 pm
Hi André,

Despite of disk full-error, here each installed member of the non-legacy Mozilla family now has its own copy of those FF/SM/TB DLLs. No RPM, so no RPM to accidently unmark DLLs marked to use memory > 512 MiB. I'm pretty sure moving the DLLs did make sense, and I would be overdoing it when I'd move those DLLs to a LIBPATH directory. And I don't have to delete all duplicate DLLs after each update.

InsTurbo should support both setups, with or without optionally (ab)using BEGINLIBPATH in case you've got several installed copies of DLLs.

Disk space is cheap now, so no problem there. I worry more about the DLL conflicts between the RPM and non-RPM stuff.

Since I do not have multiple versions of the Mozilla products in use, only run FF actually, I do not use the BEGINLIBPATH and simply invoke the program by executing it's EXE.

For now I marked the regular DLLs code-high and updated to the new turbo-07 release. I looked at the script you wrote but do not know REXX enough to understand all the pieces, can you tell me which DLLs do actually mark for load-high?

I see the following reference in Dave's CHANGES file:
25-05-2019 -v0.7 Support loading the NSPR and NSS DLLs high for SUa2 release of Mozilla

...so far now I attempted to mark high the matching files:

Code: [Select]
[G:\apps\tcpip\firefox]dir ns*dll

The volume label in drive G is OS2.
The Volume Serial Number is 45B6:75C3.
Directory of G:\apps\tcpip\firefox

 5-04-19  12:34a    137493           0  nspr4.dll
 5-04-19   2:04a    500726           0  nss3.dll
 5-04-19   2:04a    270578           0  nssckbi.dll
 5-04-19   2:03a     72331           0  nssdbm3.dll
 5-04-19   2:03a     74803           0  nssutil3.dll
        5 file(s)    1055931 bytes used
                 157243400 K bytes free

[G:\apps\tcpip\firefox]highmem -c ns*dll
Error: "nspr4.dll" cannot be opened, rc=5.
Processing module : nss3.dll
Processing module : nssckbi.dll
Processing module : nssdbm3.dll
Processing module : nssutil3.dll

Not sure why nspr4.dll failed, repmod didn't have any effect, I suppose I will try again after a re-boot in case something's still holding it:

Code: [Select]
[G:\apps\tcpip\firefox]repmod nspr4.dll -u
Unlock module 'nspr4.dll'
Locked OS/2 module unlocked successfully

[G:\apps\tcpip\firefox]highmem -c nspr4.dll
Error: "nspr4.dll" cannot be opened, rc=5.
Title: Re: Security fixes for Mozilla
Post by: xynixme on July 21, 2019, 07:12:32 pm
Always manually unload any turbo's (if loaded), close FF/SM/TB, unlock the specific DLL now (just to be sure), and ATTRIB -R the specific DLL (if read-only), if you really don't want to use InsTurbo.CMD of MozTurbo. A newer InsTurbo.EXE with a PM UI is still the subject of a senior management's review, FWIW. As requested by Dave, any InsTurbo (component of his MozTurbo package) would have taken care of this read-only setting for you.

Execute the matching ATTRIB +R later, if that's the issue. Probably, according to the OS/2 command HELP [rc_number_of_HIGMMEM], i.e. "HELP 5".

Title: Re: Security fixes for Mozilla
Post by: Dave Yeo on July 21, 2019, 08:02:00 pm
The build process leaves some of the DLLs readonly and a readonly DLL can't be marked.
As I said, the binaries, both Firefox.exe and ffturbo.exe take care of setting BEGINLIBPATH and LIBPATHSTRICT so no worries about DLL conflicts.
I regularly run SM, TB and FF without any scripts or RUN!
Title: Re: Security fixes for Mozilla
Post by: Dariusz Piatkowski on July 21, 2019, 09:03:14 pm
Always manually unload any turbo's (if loaded), close FF/SM/TB, unlock the specific DLL now (just to be sure), and ATTRIB -R the specific DLL (if read-only)...

...aha!!! I forgot about the read-only flag...indeed sir, there it is.

...Execute the matching ATTRIB +R later, if that's the issue. Probably, according to the OS/2 command HELP [rc_number_of_HIGMMEM], i.e. "HELP 5".

What is neat about this, and I had absolutely no idea after all these years, is that the program RC actualy translates to a system SYSxxx value. Of course that would rely on the code logic to actually pass this to the output w/o it being changes, but I never actually thought to check that, thank you for pointing it out!

André, one last thing though, what DLLs for FF are flagged as high-mem load eligible? No, I do not like a pre-made script doing this type of stuff for me, I do it by hand and that has always worked reliably here. This is mostly due to hold old my install is and how many numerous upgrades it has gone through, etc. etc. etc...
Title: Re: Security fixes for Mozilla
Post by: Dariusz Piatkowski on July 21, 2019, 09:05:53 pm
Hey Dave!

The build process leaves some of the DLLs readonly and a readonly DLL can't be marked.
As I said, the binaries, both Firefox.exe and ffturbo.exe take care of setting BEGINLIBPATH and LIBPATHSTRICT so no worries about DLL conflicts.
I regularly run SM, TB and FF without any scripts or RUN!

Indeed, that was the issue. I am correcting this right now. I know you said this already, but thanks for pointing this out again, never hurts for this type of stuff to be re-iterated!
Title: Re: Security fixes for Mozilla
Post by: xynixme on July 21, 2019, 09:48:30 pm
that the program RC actualy translates to a system SYSxxx value. Of course that would rely on the code logic to actually pass this to the output w/o it being changes, but I never actually thought to check that, thank you for pointing it out!

Exactly. I'll use the OS API DosOpen() to open the file (to write to it), and prints (not returns) the RC of the OS API when it's not 0. One day programmers may even decide to print SYS0005 instead of rc=5...

My source were several articles by Dave. Check the source code of InsTurbo.CMD to find DLLs compiled/supported by him. A (probably incomplete) list of other DLLs, not compiled/supported by Dave, can be found in OTHERDLLS.ZIP @ Hobbes. An example of such a DLL is HUNSPEL0.DLL. A recent RPM upgrade could overwrite such a marked DLL.

So check the source code of both InsTurbo (MozTurbo package) and OTHERDLLS.ZIP @ Hobbes. It's Rexx/text, so lists of DLLs should be easy to find. OTHERDLLS.ZIP works like InsTurbo.CMD. Or just use those tools.
Title: Re: Security fixes for Mozilla
Post by: xynixme on July 21, 2019, 10:07:40 pm
I do it by hand and that has always worked reliably here. This is mostly due to hold old my install is and how many numerous upgrades it has gone through, etc. etc. etc...

The scripts will find the same DLLs as FF/SM/TB, and the same etcetera's apply to me. I'm not using RPM myself, for example. You'll be fine, and additionally you can even control the order of LIBPATH directories by using BEGINLIBPATH.

InsTurbo was requested and distributed by Dave, so you should be fine. It ain't a third-party "works for me" project. So far no known complaints, albeit the latest code supports (rare) long directory names better.
Title: Re: Security fixes for Mozilla
Post by: Dave Yeo on July 22, 2019, 02:38:49 am
Personally, while some of the DLLs in /usr/lib can be marked high, so far I've left them alone. They do take up some low memory. but it does get properly released though over the long term there may be fragmentation. If you do mark any high, have to consider that some other programs might not like it. I tried marking Cairo high at one point and the screensaver seemed to get unstable when using the Cairo modules. Might have been a coincidence.
Eventually we'll have to consider the QT libs and some  mark the Java libs to load high. There's the same problem then of the kernel not properly releasing memory. Mozturbo could easily be adapted for others and if I was more skillful, I'd write a general purpose utility that reads a list and keeps them loaded.
Title: Re: Security fixes for Mozilla
Post by: xynixme 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.
Title: Re: Security fixes for Mozilla
Post by: Dave Yeo 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.
 
Title: Re: Security fixes for Mozilla
Post by: xynixme 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.
Title: Re: Security fixes for Mozilla
Post by: xynixme 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.
Title: Re: Security fixes for Mozilla
Post by: Jochen Schäfer 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?

Title: Re: Security fixes for Mozilla
Post by: Dave Yeo 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.
Title: Re: Security fixes for Mozilla
Post by: Jochen Schäfer on July 23, 2019, 11:54:17 am
Can we help?
Title: Re: Security fixes for Mozilla
Post by: Dariusz Piatkowski 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!