Bug 31714 - Board decision needed!!! (was:chromium-browser-stable 111.0.5563.147 security update)
Summary: Board decision needed!!! (was:chromium-browser-stable 111.0.5563.147 security...
Status: RESOLVED WONTFIX
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Nicolas Lécureuil
QA Contact: Sec team
URL:
Whiteboard:
Keywords: IN_RELEASENOTES9
Depends on: 31800
Blocks:
  Show dependency treegraph
 
Reported: 2023-03-22 12:47 CET by christian barranco
Modified: 2023-07-01 22:27 CEST (History)
15 users (show)

See Also:
Source RPM: chromium-browser-stable-111.0.5563.64-1.mga8.src.rpm
CVE:
Status comment:


Attachments

Description christian barranco 2023-03-22 12:47:59 CET
Hi. Upstream just released
https://chromereleases.googleblog.com/2023/03/stable-channel-update-for-desktop.html
Comment 1 christian barranco 2023-03-23 22:01:20 CET
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

Comment 2 David Walser 2023-03-23 22:39:09 CET
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

Comment 3 christian barranco 2023-03-23 22:59:48 CET
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.
Comment 4 David Walser 2023-03-23 23:10:42 CET
It can move to tainted for Mageia 9, but not Mageia 8.
Comment 5 Morgan Leijström 2023-03-24 10:54:56 CET
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

Comment 6 Dave Hodgins 2023-03-24 18:31:59 CET
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

Comment 7 David Walser 2023-03-25 00:05:04 CET
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.
Comment 8 katnatek 2023-03-25 02:51:20 CET
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
Comment 9 Morgan Leijström 2023-03-25 12:15:52 CET
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
Comment 10 Morgan Leijström 2023-03-25 12:18:25 CET
(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
Comment 11 David Walser 2023-03-25 12:50:04 CET
What happens with it in Mageia 9 is open to discussion.  We just can't make a major change like this in Mageia 8.
Comment 12 christian barranco 2023-03-26 21:50:09 CEST
(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.
Comment 13 christian barranco 2023-03-26 21:51:02 CEST
(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.
Comment 14 Dave Hodgins 2023-03-26 23:29:15 CEST
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.
Comment 15 David Walser 2023-03-26 23:33:33 CEST
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.
Comment 16 katnatek 2023-03-26 23:59:24 CEST
(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
Comment 17 katnatek 2023-03-27 00:02:53 CEST
(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 ?)
Comment 18 christian barranco 2023-03-27 13:18:48 CEST
(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.
Comment 19 katnatek 2023-03-27 19:49:50 CEST
(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
Comment 20 christian barranco 2023-03-28 08:09:43 CEST
Hi. Who is entitled to take the decision? 
Because, right now, the default decision is no update becomes available to the users.
Comment 21 christian barranco 2023-03-28 13:03:46 CEST
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

Comment 22 David Walser 2023-03-28 14:19:00 CEST
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.
Comment 23 christian barranco 2023-03-28 14:38:49 CEST
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.
Comment 24 David Walser 2023-03-28 18:07:19 CEST
I have no objection to Nicolas's suggestions.
Comment 25 Dave Hodgins 2023-03-28 19:44:28 CEST
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.
Comment 26 christian barranco 2023-03-28 19:53:39 CEST
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.
Comment 27 christian barranco 2023-03-28 20:07:53 CEST
(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.
Comment 28 Dave Hodgins 2023-03-28 21:04:04 CEST
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.
Comment 29 Dave Hodgins 2023-03-28 21:14:26 CEST
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.
Comment 30 christian barranco 2023-03-28 21:16:38 CEST
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.
Comment 31 David Walser 2023-03-28 21:41:51 CEST
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).
Comment 32 Thomas Backlund 2023-03-28 22:05:15 CEST
(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...
Comment 33 christian barranco 2023-03-30 00:11:46 CEST
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 => bugsquad
CC: (none) => chb0

Comment 34 David Walser 2023-03-30 00:58:27 CEST
It is clear that it needs to be built in core without the H264 support.  The advisory should note the change.
Comment 35 Marja Van Waes 2023-04-02 11:49:45 CEST
(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_mageia
Summary: 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

Comment 36 Morgan Leijström 2023-04-02 12:23:11 CEST
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
Comment 37 David Walser 2023-04-02 12:42:43 CEST
(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.
Comment 38 Dave Hodgins 2023-04-02 15:09:37 CEST
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.
Comment 39 David Walser 2023-04-02 16:30:58 CEST
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.
Comment 40 Dave Hodgins 2023-04-02 20:36:12 CEST
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.
Comment 41 David Walser 2023-04-02 22:25:22 CEST
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.
Comment 42 Dave Hodgins 2023-04-03 00:09:38 CEST
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.
Comment 43 Bruno Cornec 2023-04-03 00:22:04 CEST
(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

Comment 44 Dave Hodgins 2023-04-03 00:59:31 CEST
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.
Comment 45 David Walser 2023-04-03 02:01:26 CEST
(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.
Comment 46 Dave Hodgins 2023-04-03 03:09:24 CEST
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.
Comment 47 papoteur 2023-04-03 13:30:10 CEST
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.
Comment 48 David Walser 2023-04-06 18:45:29 CEST
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
Comment 49 Dave Hodgins 2023-04-06 20:07:48 CEST
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.
Comment 50 David Walser 2023-04-06 20:31:04 CEST
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.
Comment 51 David Walser 2023-04-06 20:33:33 CEST
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.
Comment 52 Dave Hodgins 2023-04-06 21:13:11 CEST
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.
Comment 53 David Walser 2023-04-06 21:40:07 CEST
That's not a valid option.
Comment 54 Dave Hodgins 2023-04-06 21:56:18 CEST
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?
Comment 55 David Walser 2023-04-06 22:30:47 CEST
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.
Comment 56 Dave Hodgins 2023-04-06 23:01:51 CEST
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.
Comment 57 David Walser 2023-04-06 23:20:29 CEST
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).
Comment 58 Dave Hodgins 2023-04-06 23:41:25 CEST
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.
Comment 59 Dave Hodgins 2023-04-06 23:53:00 CEST
Request for a vote submitted to the board public mailing list.
Comment 60 David Walser 2023-04-07 00:07:15 CEST
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.
Comment 61 Dave Hodgins 2023-04-07 00:58:18 CEST
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.
Comment 62 David Walser 2023-04-07 01:34:41 CEST
Again, forcing removal from users' systems is not an option here.
Comment 63 Dave Hodgins 2023-04-07 01:38:15 CEST
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.
Comment 64 David Walser 2023-04-07 02:54:56 CEST
It would be highly irresponsible to do that.
Comment 65 katnatek 2023-04-07 03:36:16 CEST
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
Comment 66 Dave Hodgins 2023-04-07 03:51:03 CEST
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.
Comment 67 katnatek 2023-04-07 19:58:38 CEST
(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
Comment 68 christian barranco 2023-04-07 20:15:43 CEST
(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.
Comment 69 katnatek 2023-04-07 20:23:41 CEST
(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
Comment 70 Jean Michel Varvou 2023-04-08 08:29:53 CEST
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...
Comment 71 Neal Gompa 2023-04-08 20:24:35 CEST
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.
Comment 72 katnatek 2023-04-08 22:51:15 CEST
(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.
Comment 73 Morgan Leijström 2023-04-08 23:07:30 CEST
(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
Comment 74 Dave Hodgins 2023-04-08 23:22:46 CEST
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.
Comment 75 Dave Hodgins 2023-04-08 23:36:08 CEST
(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.
Comment 76 Jean Michel Varvou 2023-04-10 16:04:45 CEST
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/
Comment 77 David Walser 2023-04-10 16:50:54 CEST
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.
Comment 78 Dave Hodgins 2023-04-10 17:38:48 CEST
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?
Comment 79 David Walser 2023-04-10 21:01:07 CEST
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.
Comment 80 Neal Gompa 2023-04-10 23:33:27 CEST
(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.
Comment 81 Neal Gompa 2023-04-10 23:38:21 CEST
(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.
Comment 82 christian barranco 2023-04-11 22:30:29 CEST
(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.
Comment 83 Dave Hodgins 2023-04-12 18:18:12 CEST
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

Comment 84 Thomas Backlund 2023-04-14 00:27:45 CEST
(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...
Comment 85 christian barranco 2023-04-14 20:43:56 CEST
 GCC for Chromium = very high maintenance 
Mageia 8 version is also outdated for that.
christian barranco 2023-04-15 11:48:30 CEST

Depends on: (none) => 31800

Comment 86 David Walser 2023-04-15 22:04:30 CEST
112.0.5615.121 has been released on April 14:
https://chromereleases.googleblog.com/2023/04/stable-channel-update-for-desktop_14.html
Comment 87 sturmvogel 2023-04-22 05:23:23 CEST
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
Comment 88 David Walser 2023-04-22 13:40:36 CEST
CVE-2023-2137: Heap buffer overflow in sqlite.

That will need to be fixed in sqlite3 as well.
Comment 89 David Walser 2023-05-04 17:26:31 CEST
113.0.5672.63 has been released on May 2:
https://chromereleases.googleblog.com/2023/05/stable-channel-update-for-desktop.html
Comment 90 sturmvogel 2023-05-04 19:45:32 CEST
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.
Comment 91 christian barranco 2023-05-04 22:27:10 CEST
No news on my side. Sorry for that. 
There is an ungoogled version in the MLO Tainted repo if you need something urgently.
Comment 92 Morgan Leijström 2023-05-04 22:39:01 CEST
I use flatpak
Comment 93 David Walser 2023-05-11 18:31:58 CEST
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.
Comment 94 christian barranco 2023-05-11 21:28:08 CEST
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
Comment 95 Nicolas Lécureuil 2023-05-12 11:06:56 CEST
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.
Comment 96 David Walser 2023-05-12 16:00:17 CEST
Nicolas, see Comment 93.  We may not even be able to sustain building it in Mageia 9 going forward.
Comment 97 David Walser 2023-06-01 18:15:16 CEST
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.
Comment 98 Morgan Leijström 2023-06-01 18:55:15 CEST
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

Comment 99 David Walser 2023-06-07 01:25:32 CEST
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.
Comment 100 christian barranco 2023-06-07 08:18:47 CEST
(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...
Comment 101 Nicolas Lécureuil 2023-06-18 11:04:49 CEST
we have it in tainted now for mga9

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

Comment 102 David Walser 2023-06-18 12:23:57 CEST
And what happens when we can no longer build it in Mageia 9?  Also, this bug was for Mageia 8.

Resolution: FIXED => WONTFIX

Comment 103 Morgan Leijström 2023-06-19 21:58:29 CEST
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.
Comment 104 Nicolas Lécureuil 2023-06-19 23:26:14 CEST
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 ;-)
Comment 105 Morgan Leijström 2023-06-19 23:39:51 CEST
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...
Comment 106 David Walser 2023-06-19 23:53:54 CEST
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.
Comment 107 christian barranco 2023-06-20 00:01:49 CEST
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.
Comment 108 Dave Hodgins 2023-06-20 01:40:19 CEST
What if we add llvm15 to Mageia 8, as necessary for chromium-browser-stable?
Comment 109 David Walser 2023-06-20 02:46:20 CEST
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.
Comment 110 christian barranco 2023-06-20 07:04:01 CEST
(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.
Comment 111 christian barranco 2023-06-20 11:38:03 CEST
(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.
Comment 112 Morgan Leijström 2023-06-20 17:29:22 CEST
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

Comment 113 christian barranco 2023-06-20 18:19:57 CEST
(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?
Comment 114 Nicolas Lécureuil 2023-07-01 22:27:23 CEST
already done weeks ago :-)

Note You need to log in before you can comment on or make changes to this bug.