17 thoughts on - FireFox And Plugins

• it appears to be used for playing itunes format multimedia embedded on websites

• I added this bugzilla –

  https://bugzilla.redhat.com/show_bug.cgi?id91323

• Alice Wonder wrote:

  It shows up when I run Firefox – in both about:plugins and about:addons
  -> Plugins

  If you use a central Mozilla autoconfig file setup – see, for example:

  <https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment#Configuration>

  then you can use the following line to disable this plug-in:

  lockPref(“plugin.state.librhythmbox-itms-detection-plugin”, 0);

  (and similar lines to disable any other plug-in)

  James Pearson

• –=-QuMc6TCPK/YdyF9T9LIP
  Content-Type: text/plain; charset=”UTF-8″
  Content-Transfer-Encoding: quoted-printable

  Hi,

  It is possible to rebuild the package ( for CentOS 7) and disable this plugin being built. Attached is a diff of the changes required.

  In RHEL 7.3 rhythmbox is supposed to rebase.

  https://bugzilla.redhat.com/show_bug.cgi?id=1298233

  Unsure if it has been pushed as yet, being 7.3 release day, not all info is available. What this package does contain is to be found out.

  Regards

  Phil

• Yes but then any update to rhythmbox would re-install it and it would become a pattern of build, rinse, repeat.

  Hopefully the bugzilla I filed will result in an update being pushed with the plugin either gone or available in a separate package for those who do want it.

• On Wed, Nov 02, 2016 at 09:37:03PM -0700, Alice Wonder wrote

  How about manually…

  sudo rm /usr/lib64/mozilla/plugins/librhythmbox-itms-detection-plugin.so

  You’ll have to do it each time you update rhytmbox.

• You can place the rebuilt package to a higher priority local repo.

• Walter Dnes wrote:

  … or create a very simple RPM that just has a ‘%triggerpostun’ script that removes that file each time rhythmbox is updated

  James Pearson

• I’d just put an rm -f into cron.hourly if I wanted to have RPMs that don’t verify.

  Rebuilding it with a newer version than what CentOS ships though would stop the update issue.

• –=-+jTbGpZ/IaKX6e/q3WwE
  Content-Type: text/plain; charset=”UTF-8″
  Content-Transfer-Encoding: quoted-printable

  Hi,

  Sometimes we are only left with the wash, rinse, repeat, though not ideal. This was a regular for me until I fully moved away from 6.x.

  However…

  You can update your bugzilla entry as affecting 7.3 also. The 3.3.1-5
  build in RHEL 7.3 has the same issue as you reported it.

  Note: All patches attached are against 7.3 rhythmbox 3.3.1-5 located on git.CentOS.org.

  There are a number of scenarios.

  Scenario 01:

  Disable the plugin, so it is not built and thus removed from RHEL/CentOS
  7 altogether. Not something that is likely to be done, taking away a feature.

  Attached patch referenced below does this:

  0001-Scenario-01-Disable-building-of-browser-plugin.patch

  Scenario 02:

  Move the browser plugin into a separate package. Not sure about the vendor wanting to do this, but is a viable option.

  Attached patch referenced below does this:

  0001-Scenario-02-Browser-plugin-as-seperate-package.patch

  Scenario 03:

  The CentOS community agrees with you and decides on one of the methods above and it is built and released as a ‘CentOSplus’ package.

  Regards

  Phil

• With all the talk about deleting a packaged file or rebuilding a base package, I’m surprised no one has noticed this solution. The above is most likely the best solution. Easy to deploy through CM, won’t be overwritten with package updates, and is the best for “Enterprise”
  customers (who deploy to hundreds or thousands of computers).

  I’m already using something similar to change the default home page.

• Thank you, that looks like what I originally was seeking – a way to blacklist the plugin.

  It’s still a bit puzzling that there isn’t a checkbox next to plugins in the Preferences pane.

  I gather FireFox is planning to get rid of plugin support altogether so soon it may not be an issue.

• Alice Wonder wrote:

  In ‘about:addons -> Plugins’, there is a pull down next to each plugin that has ‘Ask to Activate’, ‘Always Activate’ and ‘Never Activate’

  I believe the default is ‘Ask to Activate’ – so setting this to ‘Never Activate’ will effectively disable the plugin

  The ‘lockPref’ example in an autoconfig file forces ‘Never Activate’
  without letting users change this setting

  I believe the next ESR release (ESR 52 in March 2017) will still support NPAPI plugins – although the mainline Firefox releases after that date won’t (see https://blog.mozilla.org/futurereleases/2016/07/20/reducing-adobe-flash-usage-in-firefox/)
  – so, I guess NPAPI plugin support will still exist in Firefox shipped by RedHat/CentOS until sometime in 2018

  James Pearson

• Thanks – I was looking in the Preference panel and in about:plugins –
  that should be in the former and probably should be in the latter.

  They have some UI issues.

• Even with the plugin disabled, it still shows up in browser fingerprinting.

  Effing firefox, that’s just dumb.

  Time to rebuild the RPM without it. Er, well, I’ll wait for CentOS 7.3. Er, um, I mean branch 1611 :P

• Am 06.11.2016 um 18:37 schrieb Alice Wonder :

  as already suggested – build your own meta package with trigger scripts, to address future updates.

• Actually kind of just thinking of putting something in cron.hourly to remove it. Easier to debug if it doesn’t work. KISS.