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