On 10/06/2011 04:37 PM, Dag Wieers wrote:
On Thu, 6 Oct 2011, Yasha Karant wrote:
On 10/06/2011 04:19 PM, Dag Wieers wrote:
On Thu, 6 Oct 2011, Dr Andrew C Aitchison wrote:
> On Thu, 6 Oct 2011, Dag Wieers wrote:
> > On Thu, 6 Oct 2011, Dr Andrew C Aitchison wrote:
> > > On Thu, 6 Oct 2011, Dag Wieers wrote:
> > > > > RPMforge provides already the (beta) 64bit flash-plugin, so
> > there's > > no
> > > > need to wait for it. In this case the 64bit is installed, so
> > there is > > no
> > > > reason to install the 32bit. Unless you want to replace the
64bit
> > by > > the
> > > > 32bit.
> > > > Hmm. Unless I am using an out of date mirror RPMforge has
> > > flash-plugin.x86_64 11.0.1.129-0.1.el6.rf rpmforge
> > > > whereas the adobe-linux-i386 repo has
> > > flash-plugin.i386 11.0.1.152-release @adobe-linux-i386
> > > (Build Date: Sat 24 Sep 2011 02:45:27 AM BST).
> > > > So, why would one replace a 64bit flash-plugin with a 32bit
one ?
> > Not so much that I want to - rather that the 32 bit adobe repo was
> already enabled from when the machine was running SL5 and I have
> only now looked for the adobe-linux-x86_64 repo.
> > My real point was that the rpmforge plugin is presumably out of
> date if the adobe repo has a newer plugin with a higher release
number.
It's quite hard to release before Adobe.
I realise that except for the Fermilab/CERN staff persons, almost all
of the rest of those maintaining material for SL are unpaid
volunteers. With that stated, what is the
typical/average/median/whatever delay from the Adobe release until the
SL compatible port for the flash plugin?
In some cases, Adobe adds functionality -- but in most cases it is a
matter of bug and security-hole fixes -- and the sooner one installs a
valid security fix, the better.
Do you have proof that this is a security fix. Because I track the RHEL
packages and no such update has come through their channels. It seems as
if the release was simply their official Flash Player 11 release, rather
than a security fix.
If it is a security fix, even Red Hat is behind. Somehow I don't believe
that, but for you to provide proof of what you state. Thanks.
I use the direct Mozilla (and OpenOffice) distributions and updates.
For Firefox 7.x (that the Firefox update on Help --> About Firefox
reports as up to date), I ran an update check on the addons, including
plugins using Tools --> Add ons and URL
https://www.mozilla.org/en-US/plugincheck/ and the following was displayed:
Vulnerable plugins:
Plugin Icon
Shockwave Flash
Shockwave Flash 11.0 r1 Vulnerable (more info)
(11.0.1.129 is what actually is installed)
Thus, although I have been unable to find the vulnerability list (for
some reason, more info does not give the details but just does nothing),
Mozilla identifies this plugin as "vulnerable", presumably a security issue.
As a test, I will reload the plugin just in case there is a problem with
the Mozilla identification and the "vulnerable" warning goes away.
Just did that:
Shockwave Flash
Shockwave Flash 11.0 r1 11.0.1.0 is now "up to date"
and the actual package was:
flash-plugin-11.0.1.152-release.i386.rpm from macromedia.com
As a test, I restarted Firefox and went to
http://www.adobe.com/software/flash/about/ that responded that the
current Flash plugin is functioning ("You have version 11,0,1,152
installed" was displayed). Note that I am running IA-32 Firefox on SL
6.1 X86-64, with all necessary compatibility (IA-32) libraries installed
in a different path than the X86-64 libraries.
(As to the other respondent, I have read and am familiar with TUV policy
in https://access.redhat.com/security/updates/backporting/ . I do not
necessarily agree with this policy.)
Yasha Karant
