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

Security fixes for Mozilla

<< < (5/8) > >>

xynixme:

--- Quote from: Dariusz Piatkowski on July 21, 2019, 02:17:50 pm ---What's the best approach to managing these?
--- End quote ---
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é,


--- Quote from: André Heldoorn on July 21, 2019, 04:13:05 pm ---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.

--- End quote ---

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: ---[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

--- End code ---

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

--- End code ---

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!

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version