Hi. Upstream just released https://chromereleases.googleblog.com/2023/03/stable-channel-update-for-desktop.html
Hi, ready for QA. Please, do remember Chromium belongs now to the Tainted repo. ADVISORY NOTICE PROPOSAL ======================== New chromium-browser-stable 111.0.5563.110 fixes bugs and vulnerabilities Description The chromium-browser-stable package has been updated to the 111.0.5563.110 release, fixing 8 vulnerabilities. Some of the security fixes are: High CVE-2023-1528: Use after free in Passwords. Reported by Wan Choi of Seoul National University on 2023-03-07 High CVE-2023-1529: Out of bounds memory access in WebHID. Reported by anonymous on 2023-02-27 High CVE-2023-1530: Use after free in PDF. Reported by The UK's National Cyber Security Centre (NCSC) on 2023-02-27 High CVE-2023-1531: Use after free in ANGLE. Reported by Piotr Bania of Cisco Talos on 2023-02-13 High CVE-2023-1532: Out of bounds read in GPU Video. Reported by Mark Brand of Google Project Zero on 2023-03-03 High CVE-2023-1533: Use after free in WebProtect. Reported by Weipeng Jiang (@Krace) of VRI on 2023-03-07 High CVE-2023-1534: Out of bounds read in ANGLE. Reported by Jann Horn and Mark Brand of Google Project Zero on 2023-03-08 References https://bugs.mageia.org/show_bug.cgi?id=31714 https://chromereleases.googleblog.com/2023/03/stable-channel-update-for-desktop_21.html https://www.howtogeek.com/877321/whats-new-in-chrome-111/ SRPMS 8/tainted chromium-browser-stable-111.0.5563.110-1.mga8.tainted.src.rpm PROVIDED PACKAGES ================= x86_64 chromium-browser-111.0.5563.110-1.mga8.tainted.x86_64.rpm chromium-browser-stable-111.0.5563.110-1.mga8.tainted.x86_64.rpm i586 chromium-browser-111.0.5563.110-1.mga8.tainted.i586.rpm chromium-browser-stable-111.0.5563.110-1.mga8.tainted.i586.rpm
Assignee: chb0 => qa-bugs
We can't just move it to tainted, as those who don't have that enabled won't get updates. If you want to have a tainted version, there would still need to be a core version, but Mageia 8 is probably not the right place to introduce this.
Assignee: qa-bugs => chb0
Hi David It has been decided after the DEV ML discussion to have only one version going forward, in Tainted to benefit from the H264 bundled codecs. If we want to maintain 2 versions in Core without H264 and in Tainted with H264, it is going to be cumbersome, especially with the current performance of our BS.
It can move to tainted for Mageia 9, but not Mageia 8.
Maybe in mga8 should be in tainted backports But will be hard to find unless you know where to look And for users to really get the updates (that may be important for security), we in Mageia 8 have to have something in normal updates. For mga9 we could remove chromium from release and put it in tainted only. And we have to note that in release notes, with procedure how to get chromium in mga9 as fresh install as well as after upgrade from Mageia 8. Anyway, tested: mga8-64 OK here Clean update Swedish localisation kept opened tabs Performed same tests as I usually do for chromium; Different login types to various banking etc video sites Nothing particular in console output
CC: (none) => fri
Another option would be to issue an update in core that contains only a README.urpmi that explains that due to patent issues chromium browser is now only available in the tainted repositories. Since tainted sorts as greater then core, if the system has the tainted repos enabled, they will get the update from tainted instead of the core update.
CC: (none) => davidwhodgins
Still, this is not the kind of change that we would ever make during a stable release. Like Morgan said, it's the sort of thing that would need to be announced via the release notes to make sure that people are aware of it in advance and able to prepare for it.
I use really few this browser, is possible to make a version ready for H264, not bundling the required file and allow the download H264 part from other site or make a package that only have the H264 files? Firefox makes something like that, give the user the choice to install it or not in the user profile
My personal view is, as I wrote in the ml thread: I think we should only provide one version of Chromium. - Or not at all. We have a wiki page on installing Chrome https://wiki.mageia.org/en/Installing_Google_Chrome_in_Mageia Using flatpak both Chrome and a couple versions of chromium can be installed. I have tested that Flatpak Chromium from app/org.chromium.Chromium/x86_64/stable do support H264
(In reply to katnatek from comment #8) > is possible to make a version ready for H264, > not bundling the required file and allow the download H264 part from other > site or make a package that only have the H264 files? > > Firefox makes something like that, give the user the choice to install it or > not in the user profile Mentioned in the thread at https://ml.mageia.org/l/arc/dev/2023-03/msg00225.html
What happens with it in Mageia 9 is open to discussion. We just can't make a major change like this in Mageia 8.
(In reply to katnatek from comment #8) > I use really few this browser, is possible to make a version ready for H264, > not bundling the required file and allow the download H264 part from other > site or make a package that only have the H264 files? > > Firefox makes something like that, give the user the choice to install it or > not in the user profile Hi. Not, it doesn't work for Chromium, and we cannot do what Firefox does because of patent issue.
(In reply to David Walser from comment #11) > What happens with it in Mageia 9 is open to discussion. We just can't make > a major change like this in Mageia 8. So, no more update of Chromium without breaking WebRTC feature used so far by many users.
In my opinion, we can not continue to knowingly release patent encumbered software in the core repositories. As I see it the choices are: - Stop issuing updates for chromium browser for Mageia 8. A really bad choice from a security point of view. - Obsolete chromium browser, removing existing installed packages from users systems. - Disable WebRTC, giving Mageia users a problem that they don't encounter if they download the binaries from www.chromium.org. - Replace the chromium browser package that downloads the chromium package from chromium.org, similar to what we used to do for flash. - As per comment 6, replace the core version with a readme, and only release new updates in tainted. My preference is the last option.
Disabling WebRTC should be fine. It won't affect everyone and there are other options for those that need it. No need to inconvenience everyone using the package.
(In reply to christian barranco from comment #12) > (In reply to katnatek from comment #8) > > I use really few this browser, is possible to make a version ready for H264, > > not bundling the required file and allow the download H264 part from other > > site or make a package that only have the H264 files? > > > > Firefox makes something like that, give the user the choice to install it or > > not in the user profile > Hi. Not, it doesn't work for Chromium, and we cannot do what Firefox does > because of patent issue. Other chromium based browsers download a libffmpeg.so file for media decoding i don't know if that is enough for WebRTC
(In reply to katnatek from comment #16) > (In reply to christian barranco from comment #12) > > Other chromium based browsers download a libffmpeg.so file for media decoding > i don't know if that is enough for WebRTC That is done by rpm scripts (post ?)
(In reply to katnatek from comment #16) > (In reply to christian barranco from comment #12) > > (In reply to katnatek from comment #8) > > > I use really few this browser, is possible to make a version ready for H264, > > > not bundling the required file and allow the download H264 part from other > > > site or make a package that only have the H264 files? > > > > > > Firefox makes something like that, give the user the choice to install it or > > > not in the user profile > > Hi. Not, it doesn't work for Chromium, and we cannot do what Firefox does > > because of patent issue. > > Other chromium based browsers download a libffmpeg.so file for media decoding > i don't know if that is enough for WebRTC Hi. It is not enough. FF downloads (without really asking the user, as far as I remember) a specific Cisco plugin they should have got the authorization for.
(In reply to christian barranco from comment #18) > Hi. It is not enough. FF downloads (without really asking the user, as far > as I remember) a specific Cisco plugin they should have got the > authorization for. Ah you right, i confuse with the DRM option
Hi. Who is entitled to take the decision? Because, right now, the default decision is no update becomes available to the users.
New update: https://chromereleases.googleblog.com/2023/03/stable-channel-update-for-desktop_27.html
Summary: chromium-browser-stable 111.0.5563.110 security update => chromium-browser-stable 111.0.5563.147 security update
A simple update that disables the patented component wouldn't violate any policy, so you can already do that. For anything else, the council would need to get involved.
Hi. The direction I got today from Neoclust: *MGA8: same strategy than before ie H264 supported and one package in Core *MGA9: 2 packages: without H264 support in Core and with H264 support in Tainted.
I have no objection to Nicolas's suggestions.
I do object to knowingly shipping patent encumbered software in the core repositories. I've raised the issue on with the board, who are responsible for deciding legal issues for Mageia. While no decision has been reached, Neal has suggested ... === There is a patch for making this work with a dlopened OpenH264: https://webrtc-review.googlesource.com/c/src/+/285464 Applying this patch and then shipping OpenH264 in tainted will resolve the problem. === That way it's the people using chromium who decide whether or not to use patent encumbered software.
Hi. Have you tried the patch? Reading the comments, it doesn't help yet. In addition, even if it works, what's the point, as shipping openH264 outside, in a specific package will not help. Because of the patent discussion, it could be even worse to ship it outside.
(In reply to christian barranco from comment #26) > Hi. Have you tried the patch? Reading the comments, it doesn't help yet. > In addition, even if it works, what's the point, as shipping openH264 > outside, in a specific package will not help. Because of the patent > discussion, it could be even worse to ship it outside. To complement, I have checked Fedora sources (as noted as the use-case of the patch) and this patch is not included.
See https://wiki.mageia.org/en/Install_media_in_Mageia_for_beginners#Types_of_Mageia_media If Mageia distributes a version of chromium browser that uses the bundled h264 software in the core repository, then Mageia will likely be held responsible for violating the patents should the patent owners choose to sue. Such a lawsuit would likely mean the end of Mageia. If the version we distribute only loads the h264 codecs from the tainted repository, and only if the user has enabled the tainted repository, then user accepts the legal responsibility should the patent holders choose to sue. Same if we only ship a tainted version of chromium browser.
Note that for security of the users, if we only ship chromium in the tainted repositories, we must obsolete the core version for users who do not have the tainted repositories enabled.
Hi Dave. Yes, I am aware of that. It is why I have started to push it into Tainted and I got a pushback for MGA8. There is no option, as of now and that I am aware of, to tell Chromium to use H264 from the system. The thing is, we have been shipping Chromium with H264 for months (and maybe years). If we remove the H264 support, we'll break a feature for many users for sure. So, it looks like the MGA9 strategy to have 2 packages (without H264 in Core and with H264 in Tainted) is accepted; please, confirm. However, it is still a dead end for MGA8 and, right now, users don't get any security update anymore, but they have access to H24 when required.
Unless we remove the previous builds from the mirrors, the genie is already out of the bottle for Mageia 8. Whether we disable H264 or not, we need to update it (in core).
(In reply to David Walser from comment #31) > Unless we remove the previous builds from the mirrors, and that is exactly what needs to happend...
Hi It is ready for QA, as build is successfully completed. However, without decision, nothing is going to happen. Let me know when you are ready. Until then, I will stop pushing updates.
Assignee: chb0 => bugsquadCC: (none) => chb0
It is clear that it needs to be built in core without the H264 support. The advisory should note the change.
(In reply to christian barranco from comment #33) > Hi > It is ready for QA, as build is successfully completed. > However, without decision, nothing is going to happen. > Let me know when you are ready. Until then, I will stop pushing updates. Assigning to neoclust and CC'ing all other board members, for their decision.
CC: (none) => bruno.cornec, j.biernacki+mga, jeanmichel.varvou, maat-ml, marja11, ngompa13, ouaurelien, tmb, watersnowrock, yves.brungard_mageiaSummary: chromium-browser-stable 111.0.5563.147 security update => Board decision needed!!! (was:chromium-browser-stable 111.0.5563.147 security update)Assignee: bugsquad => mageia
In the meantime Test OK mga8-64 of core updates testing chromium-browser-stable-111.0.5563.147-1.mga8 Plasma, nvidia-current, i7, 4K screen Restored old tabs, kept settings. Swedish localisation Various login models to different banks, authority, health care A couple video sites Printing to two network printers + Boomaga Phone controls video using KDEConnect
(In reply to David Walser from comment #34) > It is clear that it needs to be built in core without the H264 support. The > advisory should note the change. This one should be clear. Anything else would violate our policies. As Thomas said, the older builds will have to be removed too.
My preference is to have a core version that only contains a README.urpmi file explaining that chromium-browser is only available in the tainted repositories and to build it there, as well as removing older builds. That would not violate our policies.
I disagree. For some, that would be akin to dropping support for the package. As stated earlier, that kind of change should only be done in a new distro version, announced in the release notes, and giving people a chance to prepare and adjust. We should not just surprisingly drop it or rip it off of people's systems.
For m9, it should be moved to tainted now. For m8, keeping it in core means that when the users upgrade either we'll have to obsolete the core version during the upgrade, or leave the users with no longer maintained versions unless they have the tainted repositories enabled. Whether we do it now in m8, or during the upgrade from m9 to m9, it has to be done. I'd rather do it now. The alternative is core only for all future releases, with Mageia having a broken version for chromium-browser. I'd rather obsolete the package and tell users to get it directly from google that do that.
For Mageia 9, it is in tainted. It will be announced in the release notes and we can expect people to read that before upgrading. At that point people can either enable tainted or uninstall the package. We don't have to do anything beyond that because the release notes will let people know what they need to do. It's not appropriate to move it midstream in a stable release unexpectedly.
Which is better for the users? Having a version that no longer supports websites that use h264 such as teams.microsoft.com or replacing the core version with a note saying that due to possible patent issues, it's now only available in the tainted repo? In my opinion, moving it to tainted now is better.
(In reply to Dave Hodgins from comment #42) > Which is better for the users? > > Having a version that no longer supports websites that use h264 such as > teams.microsoft.com or replacing the core version with a note saying that > due to possible patent issues, it's now only available in the tainted repo? > > In my opinion, moving it to tainted now is better. I'd agree *if* people were reading. If our version no longer supports websites that use h264, people will put the error message in Google Search (or whatever engine they use), and hopefully find a message on our Wiki explaining why it doesn't work anymore, and what they should do (point to tainted) so they can solve the issue. If we just provide a README, even saying the same, people won't understand why they can't find it anymore, (rather than having an error message) as they won't read that README :-( And they may leave or be more angry than having found a solution to the problem as described previously. Is there a way to modify urpmi to notify users during update that this specific package is now hosted in tainted ? (make a generic feature for urpmi, reading a list of problematic packages that are moved from repo A to repo B)
CC: (none) => bruno
Due to the 20+ hour build time, we can not provide both a core and a tainted version. It's one or the other. The workaround if we do only provide the core version is to uninstall the Mageia version, and install the version provided directly by google. That's why I'm suggesting moving to tainted now.
(In reply to Dave Hodgins from comment #42) > Which is better for the users? > > Having a version that no longer supports websites that use h264 such as > teams.microsoft.com or replacing the core version with a note saying that > due to possible patent issues, it's now only available in the tainted repo? > > In my opinion, moving it to tainted now is better. Given that disabling h264 wouldn't affect all users, it's clearly the better option.
I do not agree. Those who do not enable tainted due to either being against using patented software, or due to concern for the legal risk, will lose access to chromium with Mageia when Mageia 8 support ends which is likely to be in 4 or 5 months. For those who are willing to enable tainted, moving it now allows them to continue using chromium for sites that need h264. If you still disagree, let's put these two choices to a vote by the board.
In my opinion, there is no interest to provide Chromium without an expected feature for a big part of our users. If the unique way is to have it in tainted, go for tainted.
The tainted feature can be in tainted for Mageia 9. I wouldn't want to use a distro that would pull a stunt like moving it there during a stable cycle. Anyway, 112.0.5615.49 has been released on April 4: https://chromereleases.googleblog.com/search/label/Stable%20updates
We agree (as I understand it) that we can not continue to release updates for chromium in the core repos for Mageia 8 that have h264 support. Where we disagree is how to handle it. You're proposing that we drop h264 support for the duration of Mageia 8 for chromium, obsolete the core version in Mageia 9 and provide chromium in the tainted repo for Mageia 9. I'm proposing obsoleting the Mageia 8 core version now and providing chromium only in the tainted repository for Mageia 8 and 9. Do you agree with this summary? If so, I'll ask for a vote on the Mageia board mailing list where only board members can reply.
You don't need to obsolete anything, the tainted package in Mageia 9 will upgrade from the one in Mageia 8 just fine. People just need to be informed (via the release notes) that they will need to either enable the tainted repository or uninstall the package. You don't obsolete a package in core just to move it, but you do need to be able to get the word out at disrto version change to people so that they're aware. You can't do that midstream.
So just to summarize, if you were to switch it within Mageia 8, you would be counting on people reading the advisory and noticing it there, otherwise they silently would get no more updates for the package if they don't have tainted enabled. This business of obsoleting it is not how that would work.
The upgrade will only replace the core version with the tainted version if the tainted repositories are enabled. If they are not, we need to obsolete the unmaintained core version. In m8, I'm proposing releasing a core version with just a readme.URPMI file that would effectively remove chromium from systems that do not have the tainted repositories enabled, even if they have removed task-obsolete. If the system has the tainted repositories enabled the tainted update would replace the core version.
That's not a valid option.
In your opinion. Your position as I understand it. Drop h264 support in m8. Only have a tainted version in m9, and obsolete the core version in m9 to ensure it's removed during upgrades on systems that do not have tainted repos enabled. My position. Move to tainted for the rest of m8, and force removal of the core version with a dummy core update for systems that do not have the tainted repositories, even if task obsolete has been removed. Do I have the positions correct to put to a board vote?
No Dave, we do not obsolete packages that we still provide. That's not how things work. The options are as I explained them in Comments 50 and 51.
Let's see if I have this right now. Your position as I understand it. Drop h264 support for the rest of m8. Only have a tainted version in m9, and rely on release notes to inform users who upgrade and do not use tainted that they should manually remove chromium. My position. Move to tainted for the rest of m8, and force removal of the core version with a dummy core update for systems that do not have the tainted repositories, even if task obsolete has been removed.
Yours is still not a valid option. Either we notify users of the move via advisory or release notes (well, it should be in the Mageia 9 release notes regardless). We don't remove packages from systems during stable releases (and we're not dropping the package, so that's not a valid option anyway).
While it's not normal to remove packages, in the case where we are putting Mageia at risk of being sued, an exception must be made. The only way to reliably do that is a dummy core update. That's my point of view. As I have your position correct, I'll put that to the the board.
Request for a vote submitted to the board public mailing list.
Removing packages from the mirrors is a separate issue from removing them from users' systems. I agree that the older h264-enabled builds should either be moved to tainted media or removed entirely from the mirrors.
As long as Mageia provide packages that were installed from the core repository are in use, I believe that puts the responsibility for the patent issues on Mageia rather then on the users. By forcing them off with a note that the package is now only available in the tainted repository, it puts the choice back into the hands of the users as to whether or not they want to use patent encumbered software. We have to do our best to mitigate any damage the incorrect location has caused. I agree the old versions will need to be removed. Luckily, they are not on the iso images.
Again, forcing removal from users' systems is not an option here.
Issuing an update for the core repo that only contains a note is an option. We can not have both h264 and non h264 versions available due to the full day it takes to build, so it has to be one or the other. Either way some people will not like it.
It would be highly irresponsible to do that.
Well its not easy as sounds to provide a version with webrtc support in debian have the same issue https://groups.google.com/g/linux.debian.bugs.dist/c/z-vLxfZrZ6A/m/QcOL2xwxBwAJ if i understand well we can't legally distribute a chromium with openhs64 even if done in tainted unless it work with cisco's openh264
The whole point of the tainted repo is to have software that is patented. See comment 28 Not all jurisdictions recognize software patents https://en.wikipedia.org/wiki/Software_patent. By keeping it in a separate repo, it's up to the user to decide whether or not to use patented software. The tainted repos are not enabled unless the user enables.
(In reply to Dave Hodgins from comment #66) > The whole point of the tainted repo is to have software that is patented. > See comment 28 > > Not all jurisdictions recognize software patents > https://en.wikipedia.org/wiki/Software_patent. By keeping it in a separate > repo, it's up to the user to decide > whether or not to use patented software. The tainted repos are not enabled > unless the user enables. Yes but reading the post is clear that is safer for mageia uses cisco's openh264 in chromium than one build by mageia. I'll keep watching this waiting the final resolution
(In reply to katnatek from comment #67) > (In reply to Dave Hodgins from comment #66) > > The whole point of the tainted repo is to have software that is patented. > > See comment 28 > > > > Not all jurisdictions recognize software patents > > https://en.wikipedia.org/wiki/Software_patent. By keeping it in a separate > > repo, it's up to the user to decide > > whether or not to use patented software. The tainted repos are not enabled > > unless the user enables. > > Yes but reading the post is clear that is safer for mageia uses cisco's > openh264 in chromium than one build by mageia. Using an external package of H264 doesn't work. The openH264 codec provided as a bundle with Chromium must be used.
(In reply to christian barranco from comment #68) > Using an external package of H264 doesn't work. The openH264 codec provided > as a bundle with Chromium must be used. Sad to read, does the chromium's flatpak have this support? Coulld be an alternative for who need the combination chromium+webrtc if the final resolution is keep the free chromium's version
Hi As I understand it, OpenH264 is an open source software library developed by Cisco Systems and released under the terms of the simplified BSD licence1 . The source of the codec is available, but only the binary provided by Cisco can be used legally because patents do not allow modifications. Cisco bears the costs if one downloads the binaries. If a project uses the source, it has to cover the MPEG LA license fees (see http://www.openh264.org/faq.html ) If we want to do things properly, we would have to download the openH264 binary at the time of installation, with the licensing costs being borne by Cisco. This is the solution adopted by Mozilla. Christian specifies that at this stage this mechanism does not work with Chromium. So personally, in order to limit the risks, I would be in favour of disabling H264 support. It is penalizing for users, but there are possible workarounds (firefox, client teams, etc..) If you guarantee me 100% that we don't risk anything by activating the H264 support of chromium if the package is available via the s tainted repository, in that case I'm in favour of this option. But you need a legal basis to answer this question...
As I noted in the board-public discussion, my vote would be for stripping H.264 support from Chromium entirely in Mageia builds and keeping it in core for both M8 and M9. If people need H.264 working in the browser, Firefox will happily do what you want for this. For Chromium, it'll happily use H.264 from ffmpeg if the tainted version is installed except for WebRTC. There is an upstream bug about having WebRTC using a binary OpenH264 library: https://bugs.chromium.org/p/webrtc/issues/detail?id=14717 Beyond that, when it comes to common WebRTC things... Zoom doesn't use WebRTC codecs and relies on WebAssembly to ship their own thing based on MPEG-4 Part 10 Annex G (H.264 SVC). Google Meet uses VP8 or VP9. Jitsi is the same. Discord will use either H.264 or AV1. AWS Chime (which powers Slack huddles) uses VP9. Element Call uses VP8 or VP9. Microsoft Teams uses H.264 for camera video and AV1 for screenshare video. And it is supposed to work on Firefox now: https://www.microsoft.com/en-us/microsoft-365/roadmap?filters=Launched&searchterms=firefox If people need a Chromium with WebRTC H.264 support before the WebRTC issue is fixed, they can get either Google Chrome or Microsoft Edge.
(In reply to Neal Gompa from comment #71) > If people need a Chromium with WebRTC H.264 support before the WebRTC issue > is fixed, they can get either Google Chrome or Microsoft Edge. What about chromium flatpak ? have or not support for that ? Looky me still not have to use Teams , but seeing the alternatives (pidgin plugin not support personal accounts, official & alternative client, and chromium flatpak -if support webrtc - just support x86_64) i'll have to use in firefox.
(In reply to Morgan Leijström from comment #9) > I have tested that Flatpak Chromium from > app/org.chromium.Chromium/x86_64/stable do support H264 But please test if it works in applications, such as with webrtc
Switching to using flatpak for it does not make any difference. Google has paid for permission to distribute google chrome with h264 support bundled in. The open source chromium that we use does not have permission even though it also has the h264 support if it's enabled at build time.
(In reply to Jean Michel Varvou from comment #70) > If you guarantee me 100% that we don't risk anything by activating the H264 > support of chromium if the package is available via the s tainted > repository, in that case I'm in favour of this option. But you need a legal > basis to answer this question... No one can possibly make a 100% guarantee. There's always a risk that some court some where will consider Mageia responsible if we distribute any patent encumbered software. The entire reason the tainted repositories exist is to keep patent encumbered software in a repo that is not enabled by default. It can only be installed if the user chooses to enable the tainted repositories. By making that choice, they are accepting responsibility. At least that's the legal interpretation Mageia is using. I don't know if a lawyer was consulted before Mageia first implemented the use of the tainted repos as I wasn't on the board at that time. Even if a lawyer was consulted, there may be a court that interprets the law differently. There are no guarantees about how any law will be interpreted in every jurisdiction on the planet. If you honestly believe that risk is too great then either convince the board to drop the tainted repos and all of the software in them, or resign from the board.
Hi Thank you for this clarification. After some research, I found this article https://wiki.mageia.org/en/Software_patents_policy As Mageia is a French based association and software patents are not valid in Europe, the risk is considered low. The risk would be for the US-based organisations that host the tainted repositories. Thus, it seems acceptable to me to enable H264 support as long as the chromium software is distributed via the tainted repository. So I'm going back on my words to favour a migration from chromium to tainted. We can explain to users this change and activate the repository, knowing that mageia's policy has always been "to make Linux and free software even more accessible to all/
Right but the right way to provide that explanation to the users is via the release notes at disrto upgrade time. For Mageia 8, we can't fret about disabling something that shouldn't have been enabled to begin with.
If the approach taken is to keep it in core for m8 (with h264 disabled) and have it in tainted for m9 (with h264 enabled), then we still have to deal with upgrades from m8 to m9 for users who do use the tainted repositories. The simplest approach from my point of view is to have task-obsolete force uninstalling the core version. Otherwise the users will be left with an unmaintained version of software that has a high probability of being vulnerable to attacks by opening the wrong url. I'm now going to suggest another option. Add another build node or two and build both tainted and core versions for both m8 and m9. Before I start that conversation, Christian, is that ok with you?
No, we don't need to obsolete anything or do anything crazy. The package will automatically update just fine if people enable tainted. They will know to do this because it will be documented in the release notes. If they don't want to use tainted, they can remove the package. It really is that simple. As for having core and tainted versions, I actually like that if we can manage it.
(In reply to Jean Michel Varvou from comment #76) > Hi > > Thank you for this clarification. After some research, I found this article > https://wiki.mageia.org/en/Software_patents_policy > > As Mageia is a French based association and software patents are not valid > in Europe, the risk is considered low. The risk would be for the US-based > organisations that host the tainted repositories. > > Thus, it seems acceptable to me to enable H264 support as long as the > chromium software is distributed via the tainted repository. > > So I'm going back on my words to favour a migration from chromium to > tainted. We can explain to users this change and activate the repository, > knowing that mageia's policy has always been "to make Linux and free > software even more accessible to all/ As I said on board-public, this is not actually true. MPEG-LA maintains an up to date list of AVC/H.264 patents for countries all over the world, including European ones.
(In reply to katnatek from comment #72) > (In reply to Neal Gompa from comment #71) > > If people need a Chromium with WebRTC H.264 support before the WebRTC issue > > is fixed, they can get either Google Chrome or Microsoft Edge. > > What about chromium flatpak ? have or not support for that ? > Looky me still not have to use Teams , but seeing the alternatives (pidgin > plugin not support personal accounts, official & alternative client, and > chromium flatpak -if support webrtc - just support x86_64) > i'll have to use in firefox. The Chromium Flatpak has H.264 support enabled through Flathub's OpenH264 extension. They have customized their build so that links against OpenH264 opportunistically, similar to Fedora. However, I don't see a patch for WebRTC in there, so I don't know if that one works.
(In reply to Dave Hodgins from comment #78) > I'm now going to suggest another option. Add another build node or two and > build both tainted and core versions for both m8 and m9. Before I start that > conversation, Christian, is that ok with you? If Chromium builds with H264 support, it should build without additional effort if this support is removed. If you suggest to build 2 versions, with H264 in Taintrd and without in Core, I can manage. The issue is more on the BS load and how the QA team will manage that. FYI, Chromium 112 doesn’t build on MGA8 because of a too old clang version. I will need to find a patch for that. The age of MGA8 is actually creating more work than having two packages, one in Core and one in Tainted.
Let's go ahead with both a core and tainted version for both m8 and m9. If the build system gets too overloaded, we'll ask sysadmins to increase it's capacity. As to Chromium 112 not building, please open a bug report requesting clang 15 be provided in Mageia 8. As it's required to support this update, it's an exception that is allowed under the version update rules. Adding Thierry has to cc list regarding clang version. If the board eventually decides we can not provide an h264 version, it may mean reviewing every package we provide in tainted to see if it has patents that apply in France. We can deal with that later.
CC: (none) => thierry.vignaud
(In reply to christian barranco from comment #82) > FYI, Chromium 112 doesn’t build on MGA8 because of a too old clang version. > I will need to find a patch for that. The age of MGA8 is actually creating > more work than having two packages, one in Core and one in Tainted. you can switch to gcc too... that has been done before when we hit issues like this...
GCC for Chromium = very high maintenance Mageia 8 version is also outdated for that.
Depends on: (none) => 31800
112.0.5615.121 has been released on April 14: https://chromereleases.googleblog.com/2023/04/stable-channel-update-for-desktop_14.html
112.0.5615.165 has been released on April 18 with several fixed CVE's: https://chromereleases.googleblog.com/2023/04/stable-channel-update-for-desktop_18.html
CVE-2023-2137: Heap buffer overflow in sqlite. That will need to be fixed in sqlite3 as well.
113.0.5672.63 has been released on May 2: https://chromereleases.googleblog.com/2023/05/stable-channel-update-for-desktop.html
May i ask what the actual support status for Chromium in Mageia is? Chromium for Mageia 9 is 7 versions behind upstream (Feb 2023). Chromium for Mageia 8 is 6 versions behind upstream (Mar 2023). It is well known that for at least one CVE exploits are existing in the wild. So atm it is dangerous to use the heavily outdated Chromium versions shipped with Mageia 8/9. Browser attacks are one of the main vulnerabilties for a users system. So it is extremely important to use actual and patched browsers.
No news on my side. Sorry for that. There is an ungoogled version in the MLO Tainted repo if you need something urgently.
I use flatpak
It sounds like this Chromium problem is about to get a lot worse. From IRC: <qyliss> we try very hard to package the latest Chromium version for security reasons, but the next version of Chromium looks like it's going to require an LLVM that won't have been released yet. if your distro packages Chromium, how are you going to handle that? feels like a problem we're all going to have… <Foxboron> qyliss: This might be food for the lkml distros list possibly <Foxboron> https://lore.kernel.org/distributions/ <qyliss> ah, cheers <Foxboron> qyliss: but generally speaking, that seems like a very bad situation :/ <qyliss> *currently* it looks like it's easy to patch out, but who knows what it'll be like at release time / in future? https://github.com/NixOS/nixpkgs/issues/213862#issuecomment-1542887001 It really sounds like we should drop this package from Mageia and advise people to use the flatpak.
I can build Chromium 113 for Cauldron. For MGA8, indeed, it is another story. It would be weird Mageia drops it but not the other distributions. FYI, what Neoclust just shared with me: https://www.reddit.com/r/Mageia/comments/13eavhe/where_can_we_politely/?utm_source=share&utm_medium=android_app&utm_name=androidcss&utm_term=1&utm_content=share_button
i don't see why we should drop it for mageia 9. Squidf can provide us a version 113 for cauldron. The problem exists for mageia 8 but we won't support it for a long time after mageia 9 is out. I would propose to push new chromium in cauldron in tainted now to have an up to date version for mga9. For mageia 8 we will see in a different thread.
Nicolas, see Comment 93. We may not even be able to sustain building it in Mageia 9 going forward.
114.0.5735.90 has been released on May 30: https://chromereleases.googleblog.com/2023/05/stable-channel-update-for-desktop_30.html (In reply to David Walser from comment #96) > Nicolas, see Comment 93. We may not even be able to sustain building it in > Mageia 9 going forward. reminder that we will likely not be able to maintain this even in Mageia 9.
For now setting for release notes so we do not forget to note there IF we drop it, and suggest to use Chromium from flatpak, or https://wiki.mageia.org/en/Installing_Google_Chrome_in_Mageia
Keywords: (none) => FOR_RELEASENOTES9
114.0.5735.106 has been released on June 5: https://chromereleases.googleblog.com/2023/06/stable-channel-update-for-desktop.html It fixes an issue that is being exploited in the wild.
(In reply to David Walser from comment #99) > 114.0.5735.106 has been released on June 5: > https://chromereleases.googleblog.com/2023/06/stable-channel-update-for- > desktop.html > > It fixes an issue that is being exploited in the wild. Hi. It is being build for MGA9. MGA8 is a dead branch...
we have it in tainted now for mga9
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
And what happens when we can no longer build it in Mageia 9? Also, this bug was for Mageia 8.
Resolution: FIXED => WONTFIX
So we should 1) clone this bug to mga9, and decide if we should drop it or keep packaging. 2) announce on at least our forums, that users should because of missing security updates uninstall packaged chromium, and instead install chromium from upstream or flatpak, or use another browser, also we can suggest our wiki page on Google chrome.
we have a maintener working hard to have it available. I think we should keep it for now. We can't bet on the future ;-)
OK, so we keep the fighting spirit in Mageia 9 :) Will it only be in tainted? Please, then a note in mga9 release notes; users of chromium need to get it from there (and note the handling of disabling/enabling tainted if user do not want other packages to be updated to tainted...) We should do 2) in Comment 103, because (In reply to christian barranco from comment #100) > MGA8 is a dead branch...
Having a maintainer is great; we haven't always had that, but that doesn't fix the buildability issue in Comment 93. It definitely sounds like we should just point people to the flatpak.
So far, Fedora and openSUSE keep proposing it. I am in favor to continue as well. However, we have a very old version in MGA9 core repo and it really needs to be removed, please.
What if we add llvm15 to Mageia 8, as necessary for chromium-browser-stable?
They were attempting to do that to get it buildable for Mageia 8 now, but that's not the issue. Apparently at some point it's going to require a development snapshot of a version of llvm that hasn't even been released yet, and thus wouldn't have packaged in any Mageia version. We won't be able to build Chromium then.
(In reply to David Walser from comment #109) > They were attempting to do that to get it buildable for Mageia 8 now, but > that's not the issue. Apparently at some point it's going to require a > development snapshot of a version of llvm that hasn't even been released > yet, and thus wouldn't have packaged in any Mageia version. We won't be > able to build Chromium then. It has been the case for some time already. Indeed, it drives needs to patch to get it built with our llvm version. I have been relying a lot on onpenSUSE for some complex patches. The issue will be our llvm version lagging behind. Not changing llvm version for almost 3 years in Mageia will be / is an issue; same for gcc and not only for chromium by the way.
(In reply to Dave Hodgins from comment #108) > What if we add llvm15 to Mageia 8, as necessary for chromium-browser-stable? I have looked at that and opened a bug report. Our spec to install other versions along the current one are broken. I have fixed some of them but not all. I don’t have enough time to complete this work. Someone more knowledgeable on these packages might need less time.
For Mageia 8: asked users to switch https://forums.mageia.org/en/viewtopic.php?p=87823 For Mageia 9 the current state added in https://wiki.mageia.org/en/Mageia_9_Release_Notes#Internet_apps "Chromium-browser have moved to tainted because of patent issues and we do not want to strip popular functionality. "
Keywords: FOR_RELEASENOTES9 => IN_RELEASENOTES9
(In reply to Morgan Leijström from comment #112) > > For Mageia 9 the current state added in > https://wiki.mageia.org/en/Mageia_9_Release_Notes#Internet_apps > "Chromium-browser have moved to tainted because of patent issues and we do > not want to strip popular functionality. " Thanks Sir Who is going to remove the old package from Core on MGA9?
already done weeks ago :-)
ATM we have two pkgs waiting in mga8 updates_testing. core/updates_testing: chromium-browser-stable-111.0.5563.147-1.mga8 tainted/updates_testing: chromium-browser-stable-111.0.5563.110-1.mga8 Should we remove those or what's the situation?
(In reply to Jani Välimaa from comment #115) > ATM we have two pkgs waiting in mga8 updates_testing. > > core/updates_testing: chromium-browser-stable-111.0.5563.147-1.mga8 > tainted/updates_testing: chromium-browser-stable-111.0.5563.110-1.mga8 > > Should we remove those or what's the situation? Please remove them. Mageia 8 EOL was long ago. QA will not test and certainly not validate any Mageia 8 package, and users should have moved to Mageia 9 long ago, anyway.
OK, thanks for the info. I have cleaned all mga8 updates_testing repos to free up some space in duvel's /distrib tree.