I believe rootcerts and nss should also be included here like for the separate x86_64 if that bug only ships the 64 bits to to update repos.

I thought every update was automatically done for all architectures.
Leaving this with NicolasS as you normally update Firefox. If you do not want it, please re-assign to pkg-bugs.

Assignee: bugsquad => nicolas.salguero

I see that you have already updated Cauldron to version 128.3.0, so this is for M9.

The noarch language packs have already been pushed for i586 as part of Bug 33501, and don't have to be a part of this bug. Drakrpm-update shows them in i586, but says it can't select them because of the missing Firefox.

(In reply to Thomas Andrews from comment #4)
> The noarch language packs have already been pushed for i586 as part of Bug
> 33501, and don't have to be a part of this bug. Drakrpm-update shows them in
> i586, but says it can't select them because of the missing Firefox.

Pushing an incomplete set for an arch was a mistake.
Understandable, we are not used to push only one arch and have no routine.

@Lewis: the reason is that updates need go out both because security issues and that a tester reported some site already block the old version.
Bug 33322 have been blocking building for any other arch than x86_64, and while that is being worked on, we have shipped updates for x86_64, which is best we can for now, and us the most used arch.
This concerns Firefox and Thunderbird.

Any luck on getting 32-bit arch built?

---

@Morgan - I politely disagree.  Getting out a fix that is used on 80+% of our users' machines is good.  Why do I say 80+%.  When I was running a torrent, the x86 arch was nearly all traffic and a trickle for the 32-bit.  

So, we are doing our best to protect the 80% quickly and hopefully getting the other architectures addressed soon. 

Just my two cents <<from the peanut gallery>>

I see llvm is building again currently.

@Brian, we do agree.
What I meant was that the i10n packages should not have been pushed to /mageia/distrib/9/i586/media/core/updates/ before i586 firefox, because now i586 users get presented updates for the translation without a matching application.

Sidenote for ISO mga9 installer torrents: i have for mga9 so far share ratio 100,3 on i586, 228,7 on x86_64. I guess we are fewer who share i586 than x86_64 so the total downloads differ more.

(In reply to Morgan Leijström from comment #7)

> Sidenote for ISO mga9 installer torrents: i have for mga9 so far share ratio
> 100,3 on i586, 228,7 on x86_64. I guess we are fewer who share i586 than
> x86_64 so the total downloads differ more.

for me, total uploads for the 6 isos=1.03 GB over the last 3 days.
being at the end of the earth, and as NZ only has the 2 links to the RotW, my share ratio is a bit lower ;)

but effectively x86 is 1.5 x i586

CC: (none) => westel

mga9 i586 OK for Firefox 128.3.1
Running on Thinkpad T43, 1 GB RAM, LXDE

Surfed a nextcloud server, banking, tax office
Listened to pod
Video: forget it on this hardware/driver...


$ inxi -xSMCG
System:
  Host: localhost Kernel: 6.6.52-desktop-1.mga9 arch: i686 bits: 32
    compiler: gcc v: 12.3.0 Desktop: LXDE v: 0.10.2.r1 Distro: Mageia 9
Machine:
  Type: Laptop System: IBM product: 2668R1G v: ThinkPad T43
    serial: <superuser required>
  Mobo: IBM model: 2668R1G serial: <superuser required> BIOS: IBM
    v: 1YET62WW (1.27 ) date: 05/18/2006
CPU:
  Info: single core model: Intel Pentium M bits: 32 arch: M Dothan rev: 8
    cache: 2 MiB note: check
  Speed (MHz): 800 min/max: 800/1866 core: 1: 800 bogomips: 3723
  Flags: nx pae sse sse2
Graphics:
  Device-1: AMD RV370/M22 [Mobility Radeon X300] vendor: IBM driver: radeon
    v: kernel arch: Rage-9 bus-ID: 01:00.0
  Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X:
    loaded: radeon,v4l dri: r300 gpu: radeon resolution: 1024x768~60Hz
  API: OpenGL v: 2.1 Mesa 24.2.4 renderer: ATI RV370 direct-render: Yes

CVE-2024-9680, is also fixed by this update for architectures other than x86_64, I wonder how handle the advisory

Obviously one thing to remark is we finally fix the issues what we did have and we are releasing for all the architectures, and for other architectures than x86_64 the packages are fixing the CVEs, waiting to Nicolas make suggestion and give the list, In ask to Jani to resend firefox-128.3.1-3.mga9 for arm as rust 1.76 not was present when Nicolas send the build because a fail by space

Suggested advisory:
========================

The updated package provides Firefox 128 for all mandatory arches of Mageia (x86_64, i586 and aarch64), fixing several bugs, including security vulnerabilities, for i586 and aarch64:

Fullscreen notification dialog can be obscured by document content. (CVE-2024-7518)

Out of bounds memory access in graphics shared memory handling. (CVE-2024-7519)

Type confusion in WebAssembly. (CVE-2024-7520)

Incomplete WebAssembly exception handing. (CVE-2024-7521)

Out of bounds read in editor component. (CVE-2024-7522)

CSP strict-dynamic bypass using web-compatibility shims. (CVE-2024-7524)

Missing permission check when creating a StreamFilter. (CVE-2024-7525)

Uninitialized memory used by WebGL. (CVE-2024-7526)

Use-after-free in JavaScript garbage collection. (CVE-2024-7527)

Use-after-free in IndexedDB. (CVE-2024-7528)

Document content could partially obscure security prompts. (CVE-2024-7529)

WASM type confusion involving ArrayTypes. (CVE-2024-8385)

Type confusion when looking up a property name in a "with" block. (CVE-2024-8381)

Internal event interfaces were exposed to web content when browser EventHandler listener callbacks ran. (CVE-2024-8382)

links in an external application. (CVE-2024-8383: Firefox did not ask before openings news)

Garbage collection could mis-color cross-compartment objects in OOM conditions. (CVE-2024-8384)

SelectElements could be shown over another site if popups are allowed. (CVE-2024-8386)

Memory safety bugs fixed in Firefox 130, Firefox ESR 128.2, and Thunderbird 128.2. (CVE-2024-8387)

Compromised content process can bypass site isolation. (CVE-2024-9392)

Cross-origin access to PDF contents through multipart responses. (CVE-2024-9393)

Cross-origin access to JSON contents through multipart responses. (CVE-2024-9394)

Clipboard write permission bypass. (CVE-2024-8900)

Potential memory corruption may occur when cloning certain objects. (CVE-2024-9396)

Potential directory upload bypass via clickjacking. (CVE-2024-9397)

External protocol handlers could be enumerated via popups. (CVE-2024-9398)

Specially crafted WebTransport requests could lead to denial of service. (CVE-2024-9399)

Potential memory corruption during JIT compilation. (CVE-2024-9400)

Memory safety bugs fixed in Firefox 131, Firefox ESR 115.16, Firefox ESR 128.3, Thunderbird 131, and Thunderbird 128.3. (CVE-2024-9401)

Memory safety bugs fixed in Firefox 131, Firefox ESR 128.3, Thunderbird 131, and Thunderbird 128.3. (CVE-2024-9402)

Use-after-free in Animation timeline. (CVE-2024-9680)

References:
https://www.mozilla.org/en-US/firefox/128.1.0/releasenotes/
https://www.mozilla.org/en-US/security/advisories/mfsa2024-35/
https://www.mozilla.org/en-US/firefox/128.2.0/releasenotes/
https://www.mozilla.org/en-US/security/advisories/mfsa2024-40/
https://www.mozilla.org/en-US/firefox/128.3.0/releasenotes/
https://www.mozilla.org/fr/security/advisories/mfsa2024-47/
https://www.mozilla.org/en-US/firefox/128.3.1/releasenotes/
https://www.mozilla.org/en-US/security/advisories/mfsa2024-51/
========================

Updated package in core/updates_testing:
========================
firefox-128.3.1-3.mga9

from SRPM:
firefox-128.3.1-3.mga9.src.rpm

Assignee: nicolas.salguero => qa-bugs
CVE: CVE-2024-7519, CVE-2024-7520, CVE-2024-7521, CVE-2024-7522, CVE-2024-7524, CVE-2024-7525, CVE-2024-7526, CVE-2024-7527, CVE-2024-7528, CVE-2024-7529, CVE-2024-7531, CVE-2024-8385, CVE-2024-8381, CVE-2024-8382, CVE-2024-8383, CVE-2024-8384, CVE-2024-8386, CVE-2024-8387 => CVE-2024-7519, CVE-2024-7520, CVE-2024-7521, CVE-2024-7522, CVE-2024-7524, CVE-2024-7525, CVE-2024-7526, CVE-2024-7527, CVE-2024-7528, CVE-2024-7529, CVE-2024-8385, CVE-2024-8381, CVE-2024-8382, CVE-2024-8383, CVE-2024-8384, CVE-2024-8386, CVE-2024-8387, CVE-2024-9680
Status: NEW => ASSIGNED
Severity: major => critical

MGA9-32, Mate

$ firefox -version
Mozilla Firefox 128.3.1esr


I spent some time visiting common sites and viewed a youtube video.

Working as expected.

Additional packages for i586/aarch64

firefox-af-128.3.1-1.mga9.noarch.rpm
firefox-an-128.3.1-1.mga9.noarch.rpm
firefox-ar-128.3.1-1.mga9.noarch.rpm
firefox-ast-128.3.1-1.mga9.noarch.rpm
firefox-az-128.3.1-1.mga9.noarch.rpm
firefox-be-128.3.1-1.mga9.noarch.rpm
firefox-bg-128.3.1-1.mga9.noarch.rpm
firefox-bn-128.3.1-1.mga9.noarch.rpm
firefox-br-128.3.1-1.mga9.noarch.rpm
firefox-bs-128.3.1-1.mga9.noarch.rpm
firefox-ca-128.3.1-1.mga9.noarch.rpm
firefox-cs-128.3.1-1.mga9.noarch.rpm
firefox-cy-128.3.1-1.mga9.noarch.rpm
firefox-da-128.3.1-1.mga9.noarch.rpm
firefox-de-128.3.1-1.mga9.noarch.rpm
firefox-el-128.3.1-1.mga9.noarch.rpm
firefox-en_CA-128.3.1-1.mga9.noarch.rpm
firefox-en_GB-128.3.1-1.mga9.noarch.rpm
firefox-en_US-128.3.1-1.mga9.noarch.rpm
firefox-eo-128.3.1-1.mga9.noarch.rpm
firefox-es_AR-128.3.1-1.mga9.noarch.rpm
firefox-es_CL-128.3.1-1.mga9.noarch.rpm
firefox-es_ES-128.3.1-1.mga9.noarch.rpm
firefox-es_MX-128.3.1-1.mga9.noarch.rpm
firefox-et-128.3.1-1.mga9.noarch.rpm
firefox-eu-128.3.1-1.mga9.noarch.rpm
firefox-fa-128.3.1-1.mga9.noarch.rpm
firefox-ff-128.3.1-1.mga9.noarch.rpm
firefox-fi-128.3.1-1.mga9.noarch.rpm
firefox-fr-128.3.1-1.mga9.noarch.rpm
firefox-fur-128.3.1-1.mga9.noarch.rpm
firefox-fy_NL-128.3.1-1.mga9.noarch.rpm
firefox-ga_IE-128.3.1-1.mga9.noarch.rpm
firefox-gd-128.3.1-1.mga9.noarch.rpm
firefox-gl-128.3.1-1.mga9.noarch.rpm
firefox-gu_IN-128.3.1-1.mga9.noarch.rpm
firefox-he-128.3.1-1.mga9.noarch.rpm
firefox-hi_IN-128.3.1-1.mga9.noarch.rpm
firefox-hr-128.3.1-1.mga9.noarch.rpm
firefox-hsb-128.3.1-1.mga9.noarch.rpm
firefox-hu-128.3.1-1.mga9.noarch.rpm
firefox-hy_AM-128.3.1-1.mga9.noarch.rpm
firefox-ia-128.3.1-1.mga9.noarch.rpm
firefox-id-128.3.1-1.mga9.noarch.rpm
firefox-is-128.3.1-1.mga9.noarch.rpm
firefox-it-128.3.1-1.mga9.noarch.rpm
firefox-ja-128.3.1-1.mga9.noarch.rpm
firefox-ka-128.3.1-1.mga9.noarch.rpm
firefox-kab-128.3.1-1.mga9.noarch.rpm
firefox-kk-128.3.1-1.mga9.noarch.rpm
firefox-km-128.3.1-1.mga9.noarch.rpm
firefox-kn-128.3.1-1.mga9.noarch.rpm
firefox-ko-128.3.1-1.mga9.noarch.rpm
firefox-lij-128.3.1-1.mga9.noarch.rpm
firefox-lt-128.3.1-1.mga9.noarch.rpm
firefox-lv-128.3.1-1.mga9.noarch.rpm
firefox-mk-128.3.1-1.mga9.noarch.rpm
firefox-mr-128.3.1-1.mga9.noarch.rpm
firefox-ms-128.3.1-1.mga9.noarch.rpm
firefox-my-128.3.1-1.mga9.noarch.rpm
firefox-nb_NO-128.3.1-1.mga9.noarch.rpm
firefox-nl-128.3.1-1.mga9.noarch.rpm
firefox-nn_NO-128.3.1-1.mga9.noarch.rpm
firefox-oc-128.3.1-1.mga9.noarch.rpm
firefox-pa_IN-128.3.1-1.mga9.noarch.rpm
firefox-pl-128.3.1-1.mga9.noarch.rpm
firefox-pt_BR-128.3.1-1.mga9.noarch.rpm
firefox-pt_PT-128.3.1-1.mga9.noarch.rpm
firefox-ro-128.3.1-1.mga9.noarch.rpm
firefox-ru-128.3.1-1.mga9.noarch.rpm
firefox-sc-128.3.1-1.mga9.noarch.rpm
firefox-si-128.3.1-1.mga9.noarch.rpm
firefox-sk-128.3.1-1.mga9.noarch.rpm
firefox-sl-128.3.1-1.mga9.noarch.rpm
firefox-sq-128.3.1-1.mga9.noarch.rpm
firefox-sr-128.3.1-1.mga9.noarch.rpm
firefox-sv_SE-128.3.1-1.mga9.noarch.rpm
firefox-szl-128.3.1-1.mga9.noarch.rpm
firefox-ta-128.3.1-1.mga9.noarch.rpm
firefox-te-128.3.1-1.mga9.noarch.rpm
firefox-tg-128.3.1-1.mga9.noarch.rpm
firefox-th-128.3.1-1.mga9.noarch.rpm
firefox-tl-128.3.1-1.mga9.noarch.rpm
firefox-tr-128.3.1-1.mga9.noarch.rpm
firefox-uk-128.3.1-1.mga9.noarch.rpm
firefox-ur-128.3.1-1.mga9.noarch.rpm
firefox-uz-128.3.1-1.mga9.noarch.rpm
firefox-vi-128.3.1-1.mga9.noarch.rpm
firefox-xh-128.3.1-1.mga9.noarch.rpm
firefox-zh_CN-128.3.1-1.mga9.noarch.rpm
firefox-zh_TW-128.3.1-1.mga9.noarch.rpm

These packages will need manual actions when the update gets validated

Keywords: (none) => advisory

Katnatek, your file list does not include the i586 packages for nss or rootcerts. Are they included in this update?

(In reply to Thomas Andrews from comment #14)
> Katnatek, your file list does not include the i586 packages for nss or
> rootcerts. Are they included in this update?

I think that packages are in updates since the previous update, at less I not found related packages in testing

They got moved to updates already.

But for human reading that information they should be mentioned somehow, i think.

VM x86_64

youtube OK
mail.com OK
mageia's sites OK

RH i586
rpm -qa|grep firefox
firefox-128.3.1-3.mga9
firefox-es_MX-128.3.1-1.mga9

youtube OK
mail.com OK
mageia's sites OK

I regularly use firefox "current" so this is clean install and new profile

MGA9-32 Xfce on Foolishness, my Dell Inspiron 5100. No installation issues, tried a few sites, and was OK within the limitations of the hardware. Youtube videos have always been painful to watch on this machine, because the wifi adapter is very slow. It would probably be better with a direct connection, but that's not practical for me at the moment. Pages do render correctly, if slowly.

Also, MGA9-64 Plasma on two machines, one AMD-based, the other Intel. No issues, either with installation or with operation.

No problems noted, and this critical security update has waited far too long now. Giving it OKs on both arches, and validating.

Keywords: (none) => validated_update
Whiteboard: (none) => MGA9-64-OK MGA9-32-OK
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2024-0334.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

@ysadmin did you take care of move packages in comment#13 from testing i586,aarch64

to updates? also firefox for armv7hl not was rebuilt after the rust 1.76 build so the 128.3.1-1 noarch packages should not be moved for that architecture

I didn't do anything special to push this update. Since the version number was bumped making this a new, independent release, I expected all relevant packages to be listed in the advisory file this time. This means that there will be a mismatch in versions between the locale files (128.3.1-1.mga9) and the main firefox file (128.3.1-3.mga9) which is unexpected for users and complicates the update process for no real reason that I can see.

The mga-move-pkg log shows no armv7hl files were moved for this bug.

I'd appreciate in the future that any special install instructions be highlighted in the validation bug update comment. It's too easy to miss something important otherwise when scanning through 20 comments.

I'll move the files in comment #13 now.

Status: RESOLVED => REOPENED
CC: (none) => dan
Resolution: FIXED => (none)

(In reply to Dan Fandrich from comment #23)
> I didn't do anything special to push this update. Since the version number
> was bumped making this a new, independent release, I expected all relevant
> packages to be listed in the advisory file this time. This means that there
> will be a mismatch in versions between the locale files (128.3.1-1.mga9) and
> the main firefox file (128.3.1-3.mga9) which is unexpected for users and
> complicates the update process for no real reason that I can see.
> 
> The mga-move-pkg log shows no armv7hl files were moved for this bug.
> 
> I'd appreciate in the future that any special install instructions be
> highlighted in the validation bug update comment. It's too easy to miss
> something important otherwise when scanning through 20 comments.
> 
I really hope this is the last time we need to do this
About the 'version mismatch' of noarch packages is due to the same situation that force us to make updates just for x86_64, but as the main version is 128.3.1 they are suitable for the binary, I see this with other firefox based browser that makes security updates but as they not change strings not release langpacks for the new subversion

(In reply to Dan Fandrich from comment #23)

> 
> I'd appreciate in the future that any special install instructions be
> highlighted in the validation bug update comment. It's too easy to miss
> something important otherwise when scanning through 20 comments.
> 
I shall try to do better in the future, though like katnatek, I hope this situation doesn't come up again.

I've moved the packages for those two architectures in comment 13.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

The i18n packages' release tag has nothing to do with that of the firefox package.  It doesn't have to match, only the version does.  The dependencies work correctly so it's transparent to the user, there is no reason they would even notice.  Usually the release tags are both one, of course, but if the firefox package needs to be rebuilt for any reason, it won't.  It's happened before.

When that does happen, I used to change the release tag in SVN back to 1 after it got pushed, just to make sure that wasn't forgotten for the next update, since it was unusual to have to worry about it :o).