Bug 1648024 - mozilla-openh264 not recognized
Summary: mozilla-openh264 not recognized
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-08 19:17 UTC by Harald Reindl
Modified: 2020-10-05 01:20 UTC (History)
18 users (show)

Fixed In Version: firefox-81.0-7.fc32 firefox-81.0.1-3.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-25 12:36:24 UTC
Type: Bug


Attachments (Terms of Use)

Description Harald Reindl 2018-11-08 19:17:19 UTC
installed "mozilla-openh264.x86_64 1.8.0-1.fc28", stopped firefoxc, started again and about:plugins stil shows 1.7.1 from 2017-11 from whereever that crap is

BTW you can't set it to enable only after asking all the time, you canÄ tuninstall it in case there is a version in the user-profile which could maybe override the package version

it's all a big mess (besides the repos for fedora-cisco-openh264 where fucked up for days and did let fail any other updates at all unless you excluded it in dnf)

Comment 1 Jan Pokorný [poki] 2018-11-16 10:22:29 UTC
I've hit this too, and all this seems rather strange to me:

- gmp-gmpopenh264/1.7.1/gmpopenh264.info (mtime 2017-10-29) says:

> Version: 1.7.1

- I am not aware of ever allowing nor hand-picking respective
  libgmpopenh264.so in
  
- I have mozilla-openh264-1.8.0-2.fc30.x86_64 installed, yet it
  doesn't appear to be honored as pointed by OP

- gmpopenh264.info in Fedora's built-from-source packages never
  stated "Version: 1.7.1":

  https://codecs.fedoraproject.org/openh264/28/x86_64/m/mozilla-openh264-1.8.0-1.fc28.x86_64.rpm
  -> Version: 1.8.0

  https://codecs.fedoraproject.org/openh264/29/x86_64/m/mozilla-openh264-1.7.0-6.fc29.x86_64.rpm
  -> Version: 1.6.0

  and there was no other build in between 1.7.0-6 and 1.8.0-1
  per https://koji.fedoraproject.org/koji/packageinfo?packageID=21431


Now, colour me betrayed that Fedora did not protect my privacy and let
Firefox download some "random binary code" (exaggeration intended)
behind my back, which downright verges on whether having something like
that (which moreover proceeds without asking) in Fedora is acceptable:

> Software which downloads code bundles from the internet in order to be
> functional or useful is not acceptable for inclusion in Fedora

https://fedoraproject.org/wiki/Packaging:What_Can_Be_Packaged#Packages_which_are_not_useful_without_external_code

:-/

Comment 2 Jan Pokorný [poki] 2018-11-16 10:27:26 UTC
FWIW.

# dnf history show  mozilla-openh264
> No transaction which manipulates package 'show' was found.
> ID     | Command line             | Date and time    | Action(s)      | Altered
> -------------------------------------------------------------------------------
>   1056 | update --enablerepo fedo | 2018-11-09 09:20 | Upgrade        |    3  <
>    102 | install /var/cache/dnf/f | 2017-01-11 18:11 | Install        |    2 >

Comment 3 Jan Pokorný [poki] 2018-11-16 10:33:43 UTC
https://pagure.io/fesco/issue/2015

Comment 4 Jan Pokorný [poki] 2018-11-16 10:37:54 UTC
Harald, can you post sha256sum of libgmpopenh264.so from that user
profile if you still have it handy, please?

Comment 5 Martin Stransky 2018-11-16 10:39:35 UTC
I don't quite understand why do you file that fesco ticket and what do you expect from it? Firefox team does not decline this bugreport and we didn't refuse to work on it.

Comment 6 Martin Stransky 2018-11-16 10:45:51 UTC
Perhaps the prefs from https://bugzilla.redhat.com/show_bug.cgi?id=1155499#c22 are not sufficient now and need to be fixed.

Comment 7 Martin Stransky 2018-11-16 10:48:03 UTC
Jan, I'm a bit confused how to proceed now...do you want to leave this bug open/unfixed until it's discussed at next FESCO meeting or so? I don't want to predate your plans here.

Comment 8 Harald Reindl 2018-11-16 11:05:14 UTC
[harry@srv-rhsoft:~]$ locate libgmpopenh264.so
/mnt/data/profiles/firefox/harry/gmp-gmpopenh264/1.7.1/libgmpopenh264.so

[harry@srv-rhsoft:~]$ sha256sum /mnt/data/profiles/firefox/harry/gmp-gmpopenh264/1.7.1/libgmpopenh264.so
513277b94fd0b36c63e3ed0d29519d68c3aaa7358f191363aad1e408cccfd05d  /mnt/data/profiles/firefox/harry/gmp-gmpopenh264/1.7.1/libgmpopenh264.so

Comment 9 Martin Stransky 2018-11-16 13:47:51 UTC
I'm unable to reproduce. Steps:

1) Create a new Firefox profile ($firefox -ProfileManager) or remove gmp plugins from your recent profile (/home/komat/.mozilla/firefox/7931hc0b.webrtc/gmp in my case).
2) Run Firefox and check about:plugins - it's empty.
3) Install mozilla-openh264
4) Go to about:plugins and see

    File: system-installed
    Path: /home/komat/.mozilla/firefox/7931hc0b.webrtc/gmp-gmpopenh264/system-installed
    Version: system-installed

Perhaps if you have already installed the mozilla gmp plugin the system wide is ignored.

Comment 10 Harald Reindl 2018-11-16 13:58:49 UTC
and how do you remove that crap cleanly from the profile?

you can't disable or remove it from Firefox because the options are not available

Comment 11 Martin Stransky 2018-11-16 14:01:13 UTC
Sorry, I don't know how to remove a crap from your profile. But I used:

rm -rf /home/komat/.mozilla/firefox/7931hc0b.webrtc/gmp*

to delete the mozilla cisco plugin.

Comment 12 Jan Pokorný [poki] 2018-11-16 14:09:31 UTC
Martine, sorry for perhaps unccessary noise, I appreciate your dedication
to Firefox over and beyond, but this aspect that I only accidentally
noticed got me from a comfort zone, since I really thought I don't have
to worry about the web browser beside caring to have it updated.

And then, all of a sudden (is there any notion of "internal installation
log" in Firefox, I'd really love to avoid rumours and exclude
a possibility this was my own fault of some kind), I discover that
there's some binary code sitting in my profile, silently overriding
the system wide version I have more trust in -- I already trust
Fedora with everything else, after all).

That ticket was meant as a heads-up that things "declaratively solved"
may not be "practically solved".  With the awareness of this freedoms'
touching problem, perhaps investigation and finding of more reliable
solution for something I guess quite some time was already spent
(negoations regardin build infra -- hosting cooperation) can perhaps
be prioritized.

Hopefully this answers your question, feel free cope with the bug
and the ticker as you wish as long as the underlying problem won't
get totally ignored (cooling this down a bit is fine).

Thanks for understanding.


re [comment 8]:

Thanks, have the same file then (x86_64), so at least a partial relief.


re "reproducing" [comment 9]:

Note that it could have happened with any version I used in the past,
just for reference, my first Firefox installation was:

> Thu 05 Jan 2017
> Install firefox-50.1.0-2.fc26.x86_64              @rawhide

I can provide a list of all versions I ever had installed.

Comment 13 Martin Stransky 2018-11-16 14:20:56 UTC
Okay, Thanks for the explanation.

Please test if the fedora cisco is enabled when you remove the mozila one - which may be a different bug - see comment 9.

Comment 14 Martin Stransky 2018-11-16 15:14:10 UTC
Another problem may be that the Fedora provided mozilla-openh264 package is not installed by default and the repo is not present in the installation (IMHO). I have a clean F29 install and the mozilla-openh264 is missing. 

The plugin download itself looks disabled but when Firefox profile is migrated from old installation it may still contain the gmp* entries and thus the mozilla plugin is used.

Maybe the mozilla-openh264 should remove the plugin downloaded from mozilla when it's installed.

Comment 15 Jan Pokorný [poki] 2018-11-16 16:49:54 UTC
Thanks for looking into this.

I haven't migrated the profile, it was brand new at stated
Firefox installation time.

Per what I provided, there was apparently a window in
which just firefox without mozilla-openh264 was installed
(2017-01-05 - 2017-01-11) but I don't think I had the codec
installed, with an active consent, natively in that timeframe.
That's where said "internal installation log" would definitely
help, provided something like that exists.

Do you think Firefox would update pre-existing user-installed
codec on its own even with said protection in place if it
detected, say, that system-wide version is older that the "current"?
Why would it do so around last year's autumn up to 1.7.1 and not
subsequently to version 1.8.0?

Can Firefox install-as-override the codec into user profile by
force as an "proactive security feature"?

Note that in case there was a security finding in the library
in question, one would possibly live with a false notion of
being secure when system-wide copy updated while the one in
the user profile remained stale.


[re comment 13]:

Confirming that previously this:

> OpenH264 Video Codec provided by Cisco Systems, Inc.
> 
> File: 1.7.1
> Path: <PROFILE-PATH>/gmp-gmpopenh264/1.7.1
> Version: 1.7.1
> State: Enabled
> This plugin is automatically installed by Mozilla to comply with [...]

now has become this:

> OpenH264 Video Codec provided by Cisco Systems, Inc.
> 
> File: system-installed
> Path: <PROFILE-PATH>/gmp-gmpopenh264/system-installed
> Version: system-installed
> State: Enabled
> This plugin is automatically installed by Mozilla to comply with [...]


(Previously, there was also something like [plus view other fields]

> media.gmp-gmpopenh264.version = 1.7.1

in about:support, which now is no longer present.)

Comment 16 Harald Reindl 2018-11-17 01:44:16 UTC
> Sorry, I don't know how to remove a crap from your profile. But I used:
> rm -rf /home/komat/.mozilla/firefox/7931hc0b.webrtc/gmp*
> to delete the mozilla cisco plugin

there are 3 folders with "gmp"
 gmp
 gmp-gmpopenh264
 gmp-widevinecdm

deleted them, started firefox, about:plugins told both will be installed in a short, "updat eplugins" - voila - that crap is back

version 1.7.1 - and now?

[harry@srv-rhsoft:/mnt/data/profiles/firefox/harry]$ rpm -qa | grep h264
openh264-1.8.0-1.fc28.x86_64
gstreamer1-plugin-openh264-1.14.1-1.fc28.x86_64

Comment 17 Jan Pokorný [poki] 2018-11-19 13:33:52 UTC
I think I've found the "betraying loophole" that kicks in for me
that unfortunately stands in my way of browser maintenance workflow
(add-ons are not allowed to update automatically, on purpose):

1. go to about:addons, extensions tab
2. click on "Check for Updates" from the gear icon's popup menu
   at the top right (basic assumptions: this will only ever effect
   "extensions" [since that's where I am currenty navigated at],
   not the "plugins" in any way, but even if that was naive, for
   "extensions" that action behaves sanely, i.e., passively checks
   the updates and presents the respective options to update to
   the user)
3. voila, <PROFILE-PATH>/gmp-gmpopenh264/1.7.1 is back
   - without ever being asked about that beforehand
   - totally ignoring system-wide mozilla-openh264-1.8.0-2.fc30.x86_64
     (not to speak about pushing effectively an older version on me)
   - totally ignoring media.gmp-gmpopenh264.autoupdate=false [*]

Then indeed, I classify this as a misbehaviour interfering with perhaps
arduously established delivery scheme of proper packages in Fedora, if
if not downright crossing my freedoms.

Would also note that this behaviour was actually pointed out back then,
but in a far distant context: https://bugs.gentoo.org/525810#c13

[*] found it was introduced 3 years back when that topic was widely
    discussed:
https://src.fedoraproject.org/rpms/firefox/c/f12a1190513226091a93bb42066b9c6773438ce5

Comment 18 Martin Stransky 2018-11-19 14:54:07 UTC
I see. IIUC the bug should be "Check for Updates overrides mozilla-openh264 from Fedora", correct?

Comment 19 Martin Stransky 2018-11-19 14:57:17 UTC
(In reply to Harald Reindl from comment #16)
> > Sorry, I don't know how to remove a crap from your profile. But I used:
> > rm -rf /home/komat/.mozilla/firefox/7931hc0b.webrtc/gmp*
> > to delete the mozilla cisco plugin
> 
> there are 3 folders with "gmp"
>  gmp
>  gmp-gmpopenh264
>  gmp-widevinecdm
> 
> deleted them, started firefox, about:plugins told both will be installed in
> a short, "updat eplugins" - voila - that crap is back
> 
> version 1.7.1 - and now?

Can you please try:

1) a clean firefox profile
2) install Fedora mozilla-openh264 package to check if the mozilla-openh264 is replaced by the upstream plugin
3) check if the plugin is installed when Fedora mozilla-openh264 is missing?

Comment 20 Jan Pokorný [poki] 2018-11-20 14:43:56 UTC
re [comment 18]:
> I see. IIUC the bug should be "Check for Updates overrides
> mozilla-openh264 from Fedora", correct?

The needinfo flag is set on Harald, but I concur.

However, there's also an "plugin update can effectively downgrade it
when shadowing the system-wide plugin deployment" aspect.  Can this be
under the same umbrella or does it ask for a separate tracking ... or
is it and intentional design (if so, again, end user should be the
active arbiter to decide, IMHO)?

Comment 21 Martin Stransky 2018-11-23 15:34:44 UTC
Okay, let's me summarize what we have there:

1) If Fedora mozilla-openh264 package is missing Firefox downloads the mozilla one.
2) According to comment 17 the Fedora mozilla-openh264 package is replaced by mozilla one when manual plugin check is performed.
3) If mozilla plugin is installed the Fedora one may not be picked up - needs manual removal from user profile.

I'm not sure how to address all those issues.

IMHO the easiest way is to disable all updates from mozilla site and always have Fedora mozilla-openh264 installed. Is that possible? We can make firefox require mozilla-openh264 package from Fedora but AFAIK it's not at Fedora core repository.

A separate fixes for case 2) and 3) only on Fedora side are not realistic - we'll need a GUI for that and we'll need to backport/maintain it along the upstream Firefox.

Comment 22 Jan Pokorný [poki] 2018-11-23 17:11:05 UTC
> IMHO the easiest way is to disable all updates from mozilla site and
> always have Fedora mozilla-openh264 installed. Is that possible?

Is this meant to satisfy:
- neither 1) nor 2) can happen
- OpenH264 is available for user's needs regardless of the previous
  point
?

That sounds good, but I am afraid, "disable all updates from mozilla
site" means that management of extensions (as opposed to plugins) will
not be possible or become pretty cumbersome ... and I admit it would
likely be far greater show stopper for Fedora audience.

Ditto for some other codecs alone, perhaps.


> We can make firefox require mozilla-openh264 package from Fedora but
> AFAIK it's not at Fedora core repository.

This alone, without tackling 2) (IIUIC) or better yet, 3) will not
bring anything, right?


What I mean, perhaps the current state is the best of bad on the second
look, but is not something along 2) or 3) (or both) negotiable with
upstream?

Also would state a possible consensus solution for 2) that, with good
enough packaging discipline, could always achieve that users will be
served with Fedora round-tripped OpenH264:

  make the _plugin_ version comparison for the purpose of updating
  actually version aware (not per user-customizable field that's
  set to "system-wide" currently, but per some built-in versioning),
  and consequently, do not download anything if the current version
  (whether in the profile or system-wide) is newer-or-equal to
  Mozilla-offered one

I don't know the internals, though.

Comment 23 Martin Stransky 2018-11-24 08:44:41 UTC
(In reply to Jan Pokorný [poki] from comment #22)
> > IMHO the easiest way is to disable all updates from mozilla site and
> > always have Fedora mozilla-openh264 installed. Is that possible?
> 
> Is this meant to satisfy:
> - neither 1) nor 2) can happen
> - OpenH264 is available for user's needs regardless of the previous
>   point
> ?
> 
> That sounds good, but I am afraid, "disable all updates from mozilla
> site" means that management of extensions (as opposed to plugins) will
> not be possible or become pretty cumbersome ... and I admit it would
> likely be far greater show stopper for Fedora audience.

Sorry, I mean "disable all updates of mozilla h264 cisco plugin from mozilla sites", not all extensions.

Comment 24 Jan Pokorný [poki] 2018-11-30 17:29:17 UTC
FWIW., possible workaround preventing the codec to be unconditionally
installed while still allowing the extensions to be updated natively
is to go plugin by plugin, checking for updates at each individually,
then going to a new "available updates" subtab (if there are any),
then "Install Updates" button.  That's pretty cumbersome, though.

Comment 25 Harald Reindl 2018-12-03 13:06:02 UTC
firefox --no-remote --profile /home/harry/firefox-tmp-profile

* it's disable dby default
* after enable play-on-click
* that plugin will be installed in a short
* automatic update
* version 1.7.1

Fedora package: openh264-1.8.0-1.fc28.x86_64

> I'm unable to reproduce. Steps:
> 1) Create a new Firefox profile

did you do that?

[harry@srv-rhsoft:~]$ rm -rf /home/harry/firefox-tmp-profile
[harry@srv-rhsoft:~]$ mkdir /home/harry/firefox-tmp-profile
[harry@srv-rhsoft:~]$ firefox --no-remote --profile /home/harry/firefox-tmp-profile

frankly the plugin does not work at all from the repos and you are nearly unable to prevent the automatic install because when i switch automtaich updates from "default" to "off", stop firefox and start it again it's still at "default" which is obviously enabled

Comment 26 Harald Reindl 2018-12-03 13:09:15 UTC
that crap get nstalled in a virgin install and you can't do anything against it - no idea why you are not capable to reprodcue that

[harry@srv-rhsoft:~/firefox-tmp-profile]$ ls -lhaR gmp*
gmp:
insgesamt 12K
drwx------  2 harry verwaltung 4,0K 2018-12-03 14:05 Linux_x86_64-gcc3
drwx------  3 harry verwaltung 4,0K 2018-12-03 14:05 .
drwxr-x--- 17 harry verwaltung 4,0K 2018-12-03 14:07 ..

gmp/Linux_x86_64-gcc3:
insgesamt 8,0K
drwx------ 2 harry verwaltung 4,0K 2018-12-03 14:05 .
drwx------ 3 harry verwaltung 4,0K 2018-12-03 14:05 ..

gmp-gmpopenh264:
insgesamt 12K
drwxr-x---  3 harry verwaltung 4,0K 2018-12-03 14:07 .
drwxr-x--- 17 harry verwaltung 4,0K 2018-12-03 14:07 ..
drwxr-x---  2 harry verwaltung 4,0K 2018-12-03 14:07 1.7.1

gmp-gmpopenh264/1.7.1:
insgesamt 1,4M
drwxr-x--- 2 harry verwaltung 4,0K 2018-12-03 14:07 .
drwxr-x--- 3 harry verwaltung 4,0K 2018-12-03 14:07 ..
-rwx------ 1 harry verwaltung  116 2018-12-03 14:07 gmpopenh264.info
-rwx------ 1 harry verwaltung 1,4M 2018-12-03 14:07 libgmpopenh264.so

Comment 27 Martin Stransky 2018-12-05 16:25:07 UTC
Okay, will look at it.

Comment 28 Miro Hrončok 2019-04-25 22:26:11 UTC
This is still happening with firefox-66.0.3-1.fc30.x86_64.

I have no mozilla-openh264 installed.

$ rpm -rf ~/tmp/firefox_profile
$ mkdir ~/tmp/firefox_profile
$ firefox --no-remote --profile ~/tmp/firefox_profile

Got o Add-ons manager, Plugins.

I see "OpenH264 Video Codec provided by Cisco Systems, Inc. (disabled)" - no version is listed when I click on details

I click on "Check for Updates" - and I get "No updates found"

I go back to "Plugins" and back to "OpenH264 Video Codec provided by Cisco Systems, Inc. (disabled)" - suddenly version 1.7.1 is listed, last updated on today

I get:

$ ls -l ~/tmp/firefox_profile/gmp-gmpopenh264/1.7.1
.rwx------@  116 churchyard 26 Apr  0:14 gmpopenh264.info
.rwx------@ 1.4M churchyard 26 Apr  0:14 libgmpopenh264.so

------

$ sudo dnf install --enablerepo=fedora-cisco-openh264 mozilla-openh264  # gets me mozilla-openh264-1.8.0-3.fc30.x86_64

(repeat the steps above)

Plugins show "OpenH264 Video Codec provided by Cisco Systems, Inc. (disabled)" - "system-installed" is listed as version, updated at January 1, 1970

I click on "Check for Updates" - and I get "No updates found"

I go back to "Plugins" and back to "OpenH264 Video Codec provided by Cisco Systems, Inc. (disabled)" - suddenly version 1.7.1 is listed, last updated on today

And I get:

$ ls -l ~/tmp/firefox_profile/gmp-gmpopenh264/1.7.1
.rwx------@  116 churchyard 26 Apr  0:20 gmpopenh264.info
.rwx------@ 1.4M churchyard 26 Apr  0:20 libgmpopenh264.so


And (obviously):

$ diff /usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed/libgmpopenh264.so.1.8.0 ~/tmp/firefox_profile/gmp-gmpopenh264/1.7.1/libgmpopenh264.so
Binary files /usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed/libgmpopenh264.so.1.8.0 and /home/churchyard/tmp/firefox_profile/gmp-gmpopenh264/1.7.1/libgmpopenh264.so differ
$ diff /usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed/gmpopenh264.info ~/tmp/firefox_profile/gmp-gmpopenh264/1.7.1/gmpopenh264.info 
3c3
< Version: 1.8.0
---
> Version: 1.7.1

Comment 29 Ben Cotton 2019-05-02 19:23:56 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 30 Ben Cotton 2019-05-02 19:38:46 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 31 Jan Pokorný [poki] 2019-08-27 21:36:46 UTC
Some behind-user's-back soliciting of OpenH264 plugin was also
mentioned in a recent analysis posted on twitter:

https://twitter.com/jonathansampson/status/1165858896176660480

It contains whole a lot of unsettling facts, on-topic here is also that
mere HTTP is used for download of that plugin.  It may also be true
for the *unsolicited _downgrade_* as demonstrated (!).

Comment 32 Ben Cotton 2019-10-31 18:54:28 UTC
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 33 Ben Cotton 2019-11-27 23:18:36 UTC
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 34 Martin Stransky 2020-09-25 08:29:47 UTC
I think we may ship a patch where openh264 download is disabled completely. There's no point to download outdated plugin when Fedora has a recent one and also it's shipped by Fedora.

Comment 35 Martin Stransky 2020-09-25 12:36:24 UTC
firefox-81.0-7 has the openh264 completely disabled.

Comment 36 Fedora Update System 2020-09-25 15:09:43 UTC
FEDORA-2020-981b61a03a has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-981b61a03a

Comment 37 Fedora Update System 2020-09-25 15:09:43 UTC
FEDORA-2020-a3e1b9025c has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a3e1b9025c

Comment 38 Fedora Update System 2020-09-25 18:35:49 UTC
FEDORA-2020-a3e1b9025c has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-a3e1b9025c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a3e1b9025c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 39 Fedora Update System 2020-09-25 18:39:06 UTC
FEDORA-2020-981b61a03a has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-981b61a03a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-981b61a03a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 40 Fedora Update System 2020-09-26 01:39:11 UTC
FEDORA-2020-a3e1b9025c has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 41 Harald Reindl 2020-09-26 11:27:14 UTC
Firefox still shows it uses the randomly downloaded and outdated crap

Version 1.8.1.1
Zuletzt aktualisiert 23. Oktober 2019


mozilla-openh264-2.1.0-1.fc32.x86_64


[root@srv-rhsoft:~]$ rpm -q --changelog firefox | head
* Fr Sep 25 2020 Martin Stransky <stransky@redhat.com> - 81.0-7
- Added openh264 fixes

Comment 42 Harald Reindl 2020-09-26 11:36:09 UTC
* stopped firefox
* removed the folders "gmp", "gmp-gmpopenh264", "gmp-widevinecdm"
* after start firefox it indeed one showed using "system-installed"
* i even disabled automatic updates in Extras -> plugins
* "Widevine Content Decryption Module" was marked to get installed
* Extras -> Addons -> look for updates


Automatische Updates erlauben
Standard An Aus
Version 1.8.1.1
Zuletzt aktualisiert 26. September 2020

the shitty 1.8.1.1 is instaleld and used again and even if remove the 3 folders had solved teh issue it's unacceptable becaus enobody ut me out there is aware and capable doing so

come on are these fools at mozilla really that incompetent?

Comment 43 Martin Stransky 2020-09-26 11:40:55 UTC
Harald, your language is not acceptable and I'm not going to response to your comments unless you behave politely.

Comment 44 Harald Reindl 2020-09-26 11:44:16 UTC
reported: 2018-11-08 19:17:19 UTC 

Martin Stransky 2020-09-25 12:36:24 UTC
firefox-81.0-7 has the openh264 completely disabled

you don't need to repsond. it would be enough that you verify what you pretend after 2 years and nobody would need to say a word at all

Comment 45 Dimitris 2020-09-26 17:12:41 UTC
Martin, I still see this with 81.0-7.fc32; checking for extension updates overrides and downgrades the system-installed one.

$ dnf list installed *264*
Installed Packages
gstreamer1-plugin-openh264.x86_64                                                                1.16.2-2.fc32                                                                @fedora-cisco-openh264
mozilla-openh264.x86_64                                                                          2.1.1-1.fc32                                                                 @fedora-cisco-openh264
openh264.x86_64                                                                                  2.1.1-1.fc32                                                                 @fedora-cisco-openh264

firefox-wayland --no-remote --profile /tmp/d/ff-tmp-profile

$ find /tmp/d/ff-tmp-profile/ -iname '*gmp*'
$

about:plugins:

File: system-installed
Path: /tmp/d/ff-tmp-profile/gmp-gmpopenh264/system-installed

about:addons: check for updates

$ find /tmp/d/ff-tmp-profile/ -iname '*gmp*'
/tmp/d/ff-tmp-profile/gmp-gmpopenh264
/tmp/d/ff-tmp-profile/gmp-gmpopenh264/1.8.1.1/libgmpopenh264.so
/tmp/d/ff-tmp-profile/gmp-gmpopenh264/1.8.1.1/gmpopenh264.info

about:plugins:

File: 1.8.1.1
Path: /tmp/d/ff-tmp-profile/gmp-gmpopenh264/1.8.1.1

Comment 46 Martin Stransky 2020-09-27 12:38:42 UTC
(In reply to Dimitris from comment #45)
> Martin, I still see this with 81.0-7.fc32; checking for extension updates
> overrides and downgrades the system-installed one.
> 
> $ dnf list installed *264*
> Installed Packages
> gstreamer1-plugin-openh264.x86_64                                           
> 1.16.2-2.fc32                                                               
> @fedora-cisco-openh264
> mozilla-openh264.x86_64                                                     
> 2.1.1-1.fc32                                                                
> @fedora-cisco-openh264
> openh264.x86_64                                                             
> 2.1.1-1.fc32                                                                
> @fedora-cisco-openh264
> 
> firefox-wayland --no-remote --profile /tmp/d/ff-tmp-profile
> 
> $ find /tmp/d/ff-tmp-profile/ -iname '*gmp*'
> $
> 
> about:plugins:
> 
> File: system-installed
> Path: /tmp/d/ff-tmp-profile/gmp-gmpopenh264/system-installed
> 
> about:addons: check for updates
> 
> $ find /tmp/d/ff-tmp-profile/ -iname '*gmp*'
> /tmp/d/ff-tmp-profile/gmp-gmpopenh264
> /tmp/d/ff-tmp-profile/gmp-gmpopenh264/1.8.1.1/libgmpopenh264.so
> /tmp/d/ff-tmp-profile/gmp-gmpopenh264/1.8.1.1/gmpopenh264.info
> 
> about:plugins:
> 
> File: 1.8.1.1
> Path: /tmp/d/ff-tmp-profile/gmp-gmpopenh264/1.8.1.1

Thanks for your report. The update profile is a bit tricky but I manage to reproduce that with clear profile.
Filed a followup as Bug 1883006.

Comment 47 Fedora Update System 2020-10-01 01:29:43 UTC
FEDORA-2020-12012bf6b1 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-12012bf6b1`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-12012bf6b1

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 48 Fedora Update System 2020-10-02 01:53:13 UTC
FEDORA-2020-1c7c9d0932 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-1c7c9d0932`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1c7c9d0932

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 49 Fedora Update System 2020-10-03 02:42:01 UTC
FEDORA-2020-38b5ecdd73 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-38b5ecdd73`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-38b5ecdd73

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 50 Fedora Update System 2020-10-05 01:20:39 UTC
FEDORA-2020-38b5ecdd73 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.


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