Security fixes for Mozilla

[Dave Yeo]

Is the Mozturbo new version released yet?

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.

[ivan]

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.

[xynixme]

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/

[Dave Yeo]

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.

[Dariusz Piatkowski]

Hi Dave!

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.

[xynixme]

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.

[Dave Yeo]

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.

[Dariusz Piatkowski]

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.


[xynixme]

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".

[Dave Yeo]

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!

[Dariusz Piatkowski]

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...

[Dariusz Piatkowski]

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!

[xynixme]

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.

[xynixme]

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.

[Dave Yeo]

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.