Closed Bug 985968 Opened 10 years ago Closed 10 years ago

Mozilla Plugin check page displays Java plugin as vulnerable even if the latest Java 7 version is installed

Categories

(Websites :: plugins.mozilla.org, defect, P1)

Product:
Websites
Component:
plugins.mozilla.org
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: VarCat, Assigned: espressive)

References

Details

Attachments

(2 files)

Shockwave Plugin Version Check Updater Popup
79.64 KB, image/png
Details
Data from the URL posted in bug 959760 comment # 2
36.75 KB, text/plain
Details 
Environment:
Fx Beta 29.0b1
Build Id:20140318013849
User Agent:Mozilla/5.0 (X11; Linux i686; rv:29.0) Gecko/20100101 Firefox/29.0 
OS: Ubuntu 12.10 x86

STR:

1. Install latest Java version.
2. Go to http://www.mozilla.org/ro/plugincheck/

Expected:
Java(TM) Plug-in 10.51.2 is Up to Date

Actual:
Java(TM) Plug-in 10.51.2 vulnerable.

Note:
This issue is not reproducible on 
FF 28 release
Buil Id:20140314220517
OS: Ubuntu 12.10 x86
Blocks: 757726
Component: Plug-ins → plugins.mozilla.org
Product: Core → Websites
QA Contact: cbook
Version: 29 Branch → unspecified
Java is whitelisted in "plugins.enumerable_names" - what mimetype is plugincheck testing against here?
I mean name of course.
Sorry, i'm a little slow at the moment:
Can you paste the Java information from about:plugins here?
Flags: needinfo?(catalin.varga)
Java(TM) Plug-in 10.51.2

    File: libnpjp2.so
    Path: /usr/lib/jvm/java-7-oracle/jre/lib/i386/libnpjp2.so
    Version: 10.51.2
    State: Enabled
    Next Generation Java Plug-in 10.51.2 for Mozilla browsers

MIME Type	Description	Suffixes
application/x-java-vm	Java&#153 Plug-in	
application/x-java-applet	Java&#153 Plug-in Applet	
application/x-java-bean	Java&#153 Plug-in JavaBeans	
application/x-java-applet;version=1.1	Java&#153 Plug-in	
application/x-java-bean;version=1.1	Java&#153 Plug-in	
application/x-java-applet;version=1.1.1	Java&#153 Plug-in	
application/x-java-bean;version=1.1.1	Java&#153 Plug-in	
application/x-java-applet;version=1.1.2	Java&#153 Plug-in	
application/x-java-bean;version=1.1.2	Java&#153 Plug-in	
application/x-java-applet;version=1.1.3	Java&#153 Plug-in	
application/x-java-bean;version=1.1.3	Java&#153 Plug-in	
application/x-java-applet;version=1.2	Java&#153 Plug-in	
application/x-java-bean;version=1.2	Java&#153 Plug-in	
application/x-java-applet;version=1.2.1	Java&#153 Plug-in	
application/x-java-bean;version=1.2.1	Java&#153 Plug-in	
application/x-java-applet;version=1.2.2	Java&#153 Plug-in	
application/x-java-bean;version=1.2.2	Java&#153 Plug-in	
application/x-java-applet;version=1.3	Java&#153 Plug-in	
application/x-java-bean;version=1.3	Java&#153 Plug-in	
application/x-java-applet;version=1.3.1	Java&#153 Plug-in	
application/x-java-bean;version=1.3.1	Java&#153 Plug-in	
application/x-java-applet;version=1.4	Java&#153 Plug-in	
application/x-java-bean;version=1.4	Java&#153 Plug-in	
application/x-java-applet;version=1.4.1	Java&#153 Plug-in	
application/x-java-bean;version=1.4.1	Java&#153 Plug-in	
application/x-java-applet;version=1.4.2	Java&#153 Plug-in	
application/x-java-bean;version=1.4.2	Java&#153 Plug-in	
application/x-java-applet;version=1.5	Java&#153 Plug-in	
application/x-java-bean;version=1.5	Java&#153 Plug-in	
application/x-java-applet;version=1.6	Java&#153 Plug-in	
application/x-java-bean;version=1.6	Java&#153 Plug-in	
application/x-java-applet;version=1.7	Java&#153 Plug-in	
application/x-java-bean;version=1.7	Java&#153 Plug-in	
application/x-java-applet;jpi-version=1.7.0_51	Java&#153 Plug-in	
application/x-java-bean;jpi-version=1.7.0_51	Java&#153 Plug-in	
application/x-java-applet;deploy=10.51.2	Java&#153 Plug-in	
application/x-java-applet;javafx=2.2.51	Java&#153 Plug-in	
application/x-java-vm-npruntime	Java&#153 Plug-in
Flags: needinfo?(catalin.varga)
I don't think this problem was caused by plugin enumeration. If it was, then the Java plugin would either not show up on Plugin Check or be displayed as unrecognized.
Summary: [Linux]Mozilla plugin check page displays Java plugin as vulnerable even if the latest version is installed. → [Linux] Mozilla Plugin Pheck page displays Java plugin as vulnerable even if the latest version is installed.
Tomcat, do you know why the check fails here?
Flags: needinfo?(cbook)
Summary: [Linux] Mozilla Plugin Pheck page displays Java plugin as vulnerable even if the latest version is installed. → [Linux] Mozilla Plugin check page displays Java plugin as vulnerable even if the latest version is installed.
I'm using Nightly 31.0a1 (2014-03-20) on WinXP and https://www.mozilla.org/en-US/plugincheck/ says:

Outdated Plugins Plugin 		Status 		Action
Java(TM) Platform SE 7 U51Next Generation Java Plug-in 10.51.2 for Mozilla browsers
					vulnerable	Update Now


Opening the Java Console it says:

Java Plug-in 10.51.2.13
Using JRE version 1.7.0_51-b13 Java HotSpot(TM) Client VM


Clicking the [Update Now] Button and visiting http://www.java.com/en/download/installed.jsp says:

./ Congratulations
   You have the recommended Java installed
   Version 7 Update 51
   
   No out-of-date versions of Java were found


That's the whole 9 yards. Broken on WinXP also.
Flags: needinfo?(cbook)
Summary: [Linux] Mozilla Plugin check page displays Java plugin as vulnerable even if the latest version is installed. → Mozilla Plugin check page displays Java plugin as vulnerable even if the latest version is installed.
its not only even linux, also on win7 it shows the plugin as vulnerable.

Schalk, do you have any ideas whats going on here. I just tested this and it showed me 7u51 as vulnerable. 

So when i go to plugins.mozilla.org and let java detect on the same maschine its -> 

[copy] 	Java Deployment Toolkit 7.0.510.13 	1.7.0.51 	latest
[copy] 	Java(TM) Platform SE 7 U51 	1.7.0.51 	latest

So seems plugins.mozilla.org and plugincheck display two complete different results somehow ?
Flags: needinfo?(schalk.neethling.bugs)
Related to Bug 985056 - Java JDK 8 released ?
(In reply to Alice Wyman from comment #9)
> Related to Bug 985056 - Java JDK 8 released ?

yeah thats the latest add to plugincheck but would not explain why plugins.mozilla.org say that 1.7 is latest and plugincheck does this not :) very strange
(In reply to Carsten Book [:Tomcat] from comment #10)
> (In reply to Alice Wyman from comment #9)
> > Related to Bug 985056 - Java JDK 8 released ?
> 
> yeah thats the latest add to plugincheck but would not explain why
> plugins.mozilla.org say that 1.7 is latest and plugincheck does this not :)
> very strange

I made an RFE Bug 850992 to automate Plugin checking (Server-side) a while back.

An idea who's time has come ?
(In reply to Carsten Book [:Tomcat] from comment #10)
> yeah thats the latest add to plugincheck but would not explain why
> plugins.mozilla.org say that 1.7 is latest and plugincheck does this not :)
> very strange

Is there any difference in the type of checks they do?
I understand that Shockwave Bugs would be a new/different Bug, but under the umbrella of "this does not work".

Everything is not good ... (I have three Plugins (according to the Checker, thought I had more), and https://www.mozilla.org/en-US/plugincheck/ is mistaken about ALL of them).


...
These plugins are up to date Plugin 		Status 		Action

Shockwave for Director
Adobe Shockwave for Director Netscape plug-in, version 12.0.7.148
						12.0.7.148	Up to Date
Shockwave Flash
Shockwave Flash 12.0 r0				12.0.0.77	Up to Date


I am not so sure that there are "Shockwave for Director" and "Shockwave Flash" Plugins anymore.
There is only a "Shockwave Flash" Plugin (which apparently works for Director) that is renamed "Shockwave Player".

Version Check - Shockwave 
http://www.adobe.com/shockwave/welcome/

http://get.adobe.com/shockwave/ says "Version 12.1.0.150" is the newest Shockwave Player.

Enclosed Attachment showing the Popup that offers to update what is now called the "Shockwave Player".

I am guessing that those two Plugins were both merged and renamed.
Firefox 27.0.1 and Firefox 28 users are also reporting this with Java 7 Update 51 installed, on Windows 7, XP, Vista, and Windows 8.1. For links to support questions, see this discussion: 
https://support.mozilla.org/forums/contributors/710119 Java Plugin Check not working properly
OS: Linux → All
I see this with FF24.4.0 ESR on Win 7 x64.
(In reply to Rob from comment # 13)

> ... I have three Plugins (according to the Checker, thought I had more), and ...

With Fx 29+ [the changes were introduced in Fx 28 but 'switched off' for 28 Release]
plugins are no longer enumerable.  IMO a 'good thing' but this breaks plugincheck.

There will no longer be any "unknown" plugins.

See
"RFE an "About plugincheck" page, visible from plugincheck" bug 965812
for background and links to other bugs (including bugs where there is an issue
with there being NO "unknown", i.e. NOT tested, plugins).

> Shockwave for Director
> Adobe Shockwave for Director Netscape plug-in, version 12.0.7.148
>                                                        12.0.7.148     Up to Date
> Shockwave Flash
> Shockwave Flash 12.0 r0                                12.0.0.77      Up to Date

Adobe use different version numbers for Flash (12.0.0.77) and
"Adobe Shockwave for Director" 12.0.7.148.
Adobe release updates for these separately.  Sometimes the releases are on the same date. 

> I am guessing that those two Plugins were both merged and renamed.
Not by Adobe.

See the spreadsheet attached to bug 956905 comment # 127
where the last two dozen Adobe Security Bulletins, relating to either
Flash ("Adobe Flash Player") or Shockwave ("Adobe Shockwave Player") are reviewed
and the actual versions of Flash are documented.

In bug 956905 comment # 128 I have commented on the 'versions of Flash and Shockwave'
and recommended that the database, which is used by plugincheck, should track
the 'branches of Flash' as effectively 'separate plugins'.

This bug, about Java 8 being released and therefore 'Java 7 currently 7u51' should
NOT be detected as "vulnerable" is another example of where, IMO, the database
should have a 'separate branch' for the supported versions of Java.

See bug 956905 comment # 33 - which includes:

> (See post by Ben Bucksch (:BenB) in bug 956905 comment # 28 )
> 
> > ... Java has a version 6, 7 and 8 our there. Each of them get security fixes.
> > E.g. 6.0.55 is vulnerable and 6.0.56 has the fix, but 7.1.43 is also vulnerable to the same bug,
> > and 7.1.44 has the same fix.
> 
> Can you treat each 'Java family' as a separate Plugin?
> So, track 'Java 6' and 'Java 7' and 'Java 8' separately.


(In reply to Rob from comment # 11)
> I made an RFE Bug 850992 to automate Plugin checking (Server-side) a while back.

I agree, and I cited your RRE in bug 956905 comment # 128 (before I read this bug).


(In reply to Alice Wyman comment # 15)

> Firefox 27.0.1 and Firefox 28 users are also reporting this with Java 7 Update 51 installed,
> on Windows 7, XP, Vista, and Windows 8.1. For links to support questions, see this discussion: 
> https://support.mozilla.org/forums/contributors/710119 Java Plugin Check not working properly

The fact that Firefox 27.0.1 and Firefox 28 users are also reporting means that *this* issue
is NOT caused by "disallow enumeration of navigator.plugins" bug 757726


DJ-Leith
(In reply to Rob in comment # 7)
> Opening the Java Console it says:
> 
> Java Plug-in 10.51.2.13
> Using JRE version 1.7.0_51-b13 Java HotSpot(TM) Client VM

From Oracle:

Java SE Development Kit 7, Update 51 (JDK 7u51)

The full version string for this update release is 1.7.0_51-b13 (where "b" means "build"). The version number is 7u51.
http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html

(In reply to Carsten Book [:Tomcat] in comment # 8)
> its not only even linux, also on win7 it shows the plugin as vulnerable.
> 
> Schalk, do you have any ideas whats going on here. I just tested this and it showed
> me 7u51 as vulnerable. 
> 
> So when i go to plugins.mozilla.org and let java detect on the same maschine its -> 
> 
> [copy] 	Java Deployment Toolkit 7.0.510.13 	1.7.0.51 	latest
> [copy] 	Java(TM) Platform SE 7 U51 	1.7.0.51 	latest
> 
> So seems plugins.mozilla.org and plugincheck display two complete different results somehow ?
Have Oracle introduced a new version number in their 7u51 version?
I don't think so. I think the last change was in January 2014 (2014-01-14).
https://en.wikipedia.org/wiki/Java_version_history


I think the cause is more likely to be bug 985056 comment # 1, at 2014-03-20 08:18:23 PDT

> Carsten Book [:Tomcat] 2014-03-20 08:18:23 PDT
> 
> added the new version to plugincheck production and also 7u51 should be marked
> as latest (so not old/insecure)

Catalin Varga [QA][:VarCat] 2014-03-20 07:40:44 PDT, the OP in this bug. Very similar time.

Somehow, adding a record to the database (for Java 8) has coincided with this issue in plugincheck.

Has anybody got Java JDK 8 installed?
What does about:plugins say (compare to comment # 3)?
What does https://www.mozilla.org/en-US/plugincheck/ report for Java (compare to comment # 7)?

N.B. in comment # 7 Rob has posted
> Java(TM) Platform SE 7 U51Next Generation Java Plug-in 10.51.2 for Mozilla browsers
the Name (which is how Oracle name it 10.51.2 [or "10.51.2.13" for the full Name])
but not the Version (which I would have expected to be "Java 7 Update 51",
see bug 956905 comment # 101 - where Schalk attached a PNG, on 2014-03-10,
showing 'Java being detected' as "Java 7 Update 51").

DJ-Leith
(In reply to DJ-Leith in comment # 19)

> N.B. in comment # 7 Rob has posted
> > Java(TM) Platform SE 7 U51Next Generation Java Plug-in 10.51.2 for Mozilla browsers
> the Name (which is how Oracle name it 10.51.2 [or "10.51.2.13" for the full Name])
> but not the Version (which I would have expected to be "Java 7 Update 51",
> see bug 956905 comment # 101 - where Schalk attached a PNG, on 2014-03-10,
> showing 'Java being detected' as "Java 7 Update 51").

Tim Poll, in bug 8395206 - a duplicate of this bug, has posted a PNG from the
German plugincheck, https://www.mozilla.org/de/plugincheck/

https://bug986819.bugzilla.mozilla.org/attachment.cgi?id=8395206
I'll call this Live-DE.

This looks different to Schalk's PNG (from bug 956905 comment # 101)
https://bug956905.bugzilla.mozilla.org/attachment.cgi?id=8388579
Schalk's is from a local DEV version: I'll call this DEV.

Differences include:

Live-DE
Java Development Toolkit 7.0.510.13
NPRuntime Script Plug-in Library for Java(TM) Deploy          vulnerable

Java(TM) Platform SE 7 U51
Next Generation Java Plug-in 10.51.2 for Mozilla browsers     vulnerable


DEV
Java Runtime Environment
Displays Java applet content, or a placeholder if Java 
is not installed.                                             Java 7 Update 51


So, the descriptions are different.

Also different is Flash.

Live-DE
Adobe Shockwave for Director Netscape plug-in, version 12.1   12.1.0.150

Shockwave Flash
Shockwave Flash 12.0 r0                                       12.0.0.77


DEV
Adobe Flash Player
Shockwave Flash 12.0 r0                                       12.0.0.77

Again, the descriptions are different (I assume no "Adobe Shockwave for Director ..." is installed).

On
https://www.mozilla.org/en-GB/plugincheck/
Live-GB (and also in Live-US)

Shockwave Flash
Shockwave Flash 12.0 r0                                       12.0.0.77

I get the same as Live-DE.
I do NOT have "Shockwave for Director" and I have removed Java from this Laptop.

In bug 956905 comment # 90 Schalk has a link to a screencast.
Here his Mac is using www.mozilla.org/en-US/plugincheck and Fx 27.0.1
[Java was not working in his profile 27.0.1 profile]

This also has:

Shockwave Flash
Shockwave Flash 12.0 r0                                       12.0.0.77

So, the best to assume that the DEV screen shot (bug 956905 comment # 101) is different.


Both Rob and Tim Poll have the same: 

Java(TM) Platform SE 7 U51
Next Generation Java Plug-in 10.51.2 for Mozilla browsers     vulnerable

The version number is NOT shown, when "vulnerable" (there is no room in the Status column - which is 'normal for plugincheck'.

DJ-Leith
I think this reflects the same problem the Plugin Checker has with the Adobe Acrobat plugin. Adobe does not support Adobe Reader/Acrobat XI for Windows Vista users. The current X series plugin (10.1.9) is flagged as outdated/vulnerable for Vista users even though it is the latest available for them and supported by Adobe. There is no affirmative indication in the JSON "other" list that there is any problem with version 10.1.9.

I think a record needs to be created under "other" versions affirmatively indicating that a specific version is *not* outdated in order to avoid the alarming "false positive" in both cases.
Might I suggest two distinct user displays for problematic plug-ins?  Use "Outdated" for the latest releases of old/obsolete plugins which are still known to be OK, and "Vulnerable" for ones which are known (or reasonably suspected) to have a problem.  

This avoids the users' panic of having to update something right away, only to find they have the latest.  Also avoids users getting numbed by false "vulnerable" messages when the only viable option is to ignore these warnings.
(In reply to DJ-Leith from comment #20)
> The version number is NOT shown, when "vulnerable" (there is no room in the
> Status column - which is 'normal for plugincheck'.

There is room on the screen for a second line in the same column to show version too -- if you can find a way to display it.  Would make sense to display the plug-in version for the "unknown" plugins too, if the version can in any way be determined.
Summary: Mozilla Plugin check page displays Java plugin as vulnerable even if the latest version is installed. → Mozilla Plugin check page displays Java plugin as vulnerable even if the latest Java 7 version is installed
(In reply to Jefferson from comment #21)
> I think this reflects the same problem the Plugin Checker has with the Adobe Acrobat plugin.
> Adobe does not support Adobe Reader/Acrobat XI for Windows Vista users. ...
I agree with the whole of Jefferson's comment.  There is already bug 986588 for
"Adobe Acrobat 10.1.9 is marked as vulnerable on Windows Vista".


(In reply to Dan Pernokis from comment #23)
> (In reply to DJ-Leith from comment #20)
> > The version number is NOT shown, when "vulnerable" (there is no room in the
> > Status column - which is 'normal for plugincheck'.

> There is room on the screen for a second line in the same column to show version
> too -- if you can find a way to display it.  Would make sense to display the
> plug-in version for the "unknown" plugins too, if the version can in any way
> be determined.

I agree that there is room to show the version for "unknown" (and for "outdated" or "vulnerable")
because there is usually an Icon at the left and there is usually two lines of 'description'
for the plugin Name.  I don't ever recall seeing version numbers for "vulnerable".
The plugincheck page had a 'visual design makeover' in 2013.

I, for one, would have found it useful to see the version numbers.  I imagine that those
responsible though it better to just make a clear warning, "vulnerable" - as we see in
Tim Poll's screenshot.
https://bug986819.bugzilla.mozilla.org/attachment.cgi?id=8395206


"Unknown Plugins"
In Fx 28 you can still see "Unknown Plugins", as a separate section of the 'plugin report'.

In the 'new 29+ plugincheck service' there will be NONE of these because
the 'new 29+ plugincheck service' will only be able to test for KNOWN plugins, that are
on a 'JSON list' (which will have been generated from the 'plugin database').

See (from comment # 18)

> With Fx 29+ [the changes were introduced in Fx 28 but 'switched off' for 28 Release]
> plugins are no longer enumerable.  IMO a 'good thing' but this breaks plugincheck.
> 
> There will no longer be any "unknown" plugins.
> 
> See
> "RFE an "About plugincheck" page, visible from plugincheck" bug 965812
> for background and links to other bugs ...

I fear that users will NOT realise that there will be some 'not tested plugins' in their
Fx 29+.  So they may have a false sense of security.


See also bug 952914 where DJ-Leith wrote:

> In https://bugzilla.mozilla.org/show_bug.cgi?id=757726#c105
> Chris Peterson (:cpeterson) wrote:
> 
> >   * Renamed "plugin.enumerableNames" pref to "plugins.enumerable_names"
> >   * Added special pref value '*' to disable all plugin hiding
> 
> So if you, via "about:config", change the "plugins.enumerable_names" preference to "*"
> all sites (including 'plugincheck') can still use enumeration of ALL plugins.
> 
> Once you have been to the site that YOU want to 'allow enumeration' you can then
> either
>   'set it back to default' (right click the line and choose "Reset")
> or
>   you can browse all sites with 'no enumeration allowed' by choosing the empty string "".


FYI, since 20 December 2013, I have been using Aurora as my MAIN browser with the
"plugins.enumerable_names" preference set to "Shockwave"
(NOT the default for 28+ of "Java,Nexus Personal,QuickTime,Shockwave").
I have yet to find a site that I use (apart from plugincheck) that I can't
use.  I'm not a 'typical browser' (I do have NoScript and RequestPolicy on
ALL my profiles).

I can either use one of my release profiles (Fx 28) to do a plugincheck.
Or, I can change the "plugins.enumerable_names" preference to "*" (in 29+)
then 'do a plugincheck', then 'set the preference back to my preferred preference'.

As I write, 2014-03-25, the live plugincheck is still using enumeration of plugins.

DJ-Leith
(In reply to Dan Pernokis from comment #23)
> (In reply to DJ-Leith from comment #20)
> > The version number is NOT shown, when "vulnerable" (there is no room in the
> > Status column - which is 'normal for plugincheck'.
> 
> There is room on the screen for a second line in the same column to show
> version too -- if you can find a way to display it.  Would make sense to
> display the plug-in version for the "unknown" plugins too, if the version
> can in any way be determined.

IIRC when Java 7.0.? was (almost) released the prior Version (6.x.?) was still considered to be valid (by Sun, IIRC; maybe Oracle was not yet owner). Way back then, (not that long ago) J7 was a 'Beta' / 'Developer' version (much like our "Nightly" is the "Developer" Version).

It was months later that J7 was considered 'so stable' (more than 'just stable') that it was recommended for Java Users to upgrade.

We likely have the same situation again, where bleeding edge Folks (like "us", but not necessarily most Mozilla Browser Users) can use J8, but use of J7 is still permissible.

A simpler way of describing it (for our purposes) would be to say that J8 is a "Beta" but that is not accurate and would make some Users panic that they had been 'forced' to upgrade to an unstable Version (and the downgrade path is 'technical' (for them)).

It is a better description of the situation that J8 is a 'Developer Branch' that will be merged with J7 to make the next Version of J8; that is also not completely accurate but just a simpler way of describing it.

Another way to describe it is to say that is: 
J8 = Nightly, J7 = Aurora, and J6 = Netscape (also not accurate, but you get my point).

.

PS: Also see Comment 18 and bug 956905 comment 128 -- Automate Plugin Checking.

After (what I suspect would be) an hour of writing a Script, a day of babysitting, with a further week of testing we would have a simple way to eliminate 99% of these Bugs; with an occasional Report that the Script somehow missed something.

> (In reply to DJ-Leith from comment #18)
> ... There will no longer be any "unknown" plugins. ...
We could bring back the "unknown" Plugins (since many are actually "known") or leave them out and thus make people vulnerable to them; with the 'Automate System' so much work would be removed that it would be easy to do the checking.

It would shift the 'work' to the 'bleeding edge User' (or one of us could be that person, and trigger the Script's Database to update). There must be a few hundred of these Bug Reports in the past few years (and all the Dupes). There comes a point in time where the work needed to do things one way exceeds the work to do things the other way.

I understand there is some resistance (to be overcome) to have Server Side Scripts written (like when I suggested we automate 'Attachment file type detection' (using the Program called "File")) but that RFE sure helped the Maintainers from having to go through and check for 'default Attachment types' (where the User uploaded an Attachment but did not correctly select the File's type).
I read the Help (which was little help), it seems I do not have permission to set "Depends / Blocks" on other people's Bugs (I've been here over 4 years) ...

I suggest Bug 821279 - Tracking bug for all bugs against plugincheck .
I am using latest Aurora version with Win7
I also have the problem that the plug-in check shows that JAVA is not the latest version when it is - I think it started with v29.  

I also have the problem that not all my plug-ins are being shown or checked and this behavior did start sometime around v27 - v28.

I'll keep an eye on this - let me know if you need anything.
(In reply to Woody Barrett from comment #28)
> I am using latest Aurora version with Win7
> I also have the problem that the plug-in check shows that JAVA is not the
> latest version when it is - I think it started with v29.  
> 
> I also have the problem that not all my plug-ins are being shown or checked
> and this behavior did start sometime around v27 - v28.
> 
> I'll keep an eye on this - let me know if you need anything.

Thanks for a rough idea of the Version.


From Comment 18 :

> ... I have three Plugins (according to the Checker, thought I had more), and ...
With Fx 29+ [the changes were introduced in Fx 28 but 'switched off' for 28 Release]
plugins are no longer enumerable.  IMO a 'good thing' but this breaks plugincheck.
There will no longer be any "unknown" plugins.

From Comment 26 :
> ... There will no longer be any "unknown" plugins. ...
We could bring back the "unknown" Plugins (since many are actually "known") or leave them out and thus make people vulnerable to them; with the 'Automate System' so much work would be removed that it would be easy to do the checking.
(In reply to Rob from comment #29)
> Thanks for a rough idea of the Version.
I hope you weren't being sarcastic.  I update Aurora every day, so telling you that I'm running the latest version is actually more accurate than telling you what version I had on the day I made the post.  Also, it's not nice to diss someone whose offering to help.

>IMO a 'good thing' but this breaks plugincheck.  There will no longer be any "unknown" plugins.
Personally, I think it should be an "all or nothing" deal.  Check 'em all or check none of them - as a user, I'd be perfectly happy with either scenario.  If plug-in checking is removed and someone is unhappy with that, someone will eventually create an add-on to do the plug-in checks.
(In reply to Woody Barrett from comment #30)
> (In reply to Rob from comment #29)
> > Thanks for a rough idea of the Version.
> I hope you weren't being sarcastic.  I update Aurora every day, so telling
> you that I'm running the latest version is actually more accurate than
> telling you what version I had on the day I made the post.  Also, it's not
> nice to diss someone whose offering to help.
> 
I re-read that. It is clear that is not what is going on.
Blocks: 990857
(In reply to Catalin Varga [QA][:VarCat] from comment #0)
> Environment:
> Fx Beta 29.0b1
> Build Id:20140318013849
> User Agent:Mozilla/5.0 (X11; Linux i686; rv:29.0) Gecko/20100101
> Firefox/29.0 
> OS: Ubuntu 12.10 x86
> 
> STR:
> 
> 1. Install latest Java version.
> 2. Go to http://www.mozilla.org/ro/plugincheck/
> 
> Expected:
> Java(TM) Plug-in 10.51.2 is Up to Date
> 
> Actual:
> Java(TM) Plug-in 10.51.2 vulnerable.
> 
> Note:
> This issue is not reproducible on 
> FF 28 release
> Buil Id:20140314220517
> OS: Ubuntu 12.10 x86

Thank you for filing this Catalin, and thank you for everyone's comments so far. This is something that is caused by the change in how plugin detection needs to work with regards to Fx 29+ so, first thing for me to do is to test this scenario against the new plugin check service under development, and confirm that I can reproduce the issue.

If I cannot reproduce this, then it means this bug will be resolved as soon as the new plugincheck is released. Because there are similar bugs, I am for the time being moving this to be tracked under bugs that effect the current plugin check, until I can confirm that this also will effect the new version.
Depends on: 993750
Just an aside, given Kohei's tags (above):
Having written several duplicates myself, I know it is often difficult to find a bug that has been described already.  Looks like it just scans titles.  Is there any way to widen or improve the search process?  (The original submitters may not have titled their bug properly, and then searchers may not know how to describe theirs when looking.)
I'm watching all incoming website-related bugs so it's easy for me to find duplicates. Actually this bug can be found in the Possible Duplicates list when you type Java in the Summary field in the bug report form:

https://bugzilla.mozilla.org/enter_bug.cgi?product=Websites&component=plugins.mozilla.org

I think people should not be afraid of filing a duplicated bug, because the number of duplicates could eventually be an indicator of how may people are affected :)
4 points, in order of Urgency.

1. Urgent and most Important - short term fix.

As the cause of this is almost certainly the changes that were made to
the 'plugincheck database' in bug 985056 ("Java JDK 8 released").

Alice Wyman correctly identified this on 2014-03-21 (see comment # 9
and comment # 15).

It is better for a few Users of Plugincheck to see a message
that their 'Java 8' is one of their "Unknown Plugins"
than for the >99% of Users who have Java installed to have this
'false positive'.

Tomcat, can you revert bug 985056 and remove the record for Java
version "11.0.2.132"?

Obviously, you may wish to test this on a 'staging' or 'Dev' version
of plugincheck.


In order to install Java 8 one has to go and 'look for it': it is not
available at

"Java Downloads for All Operating Systems"
http://www.java.com/en/download/manual.jsp

See,
"Why is Java 8 not available on java.com?"
http://www.java.com/en/download/faq/java8.xml

In my opinion, reverting bug 985056 would be a better 'short term fix'
than bug 993750 - that Craig Cook is working on.

Plugincheck is important:
"... The plugin check site is ranked as the #2 site (#1 is mozilla.org) that
the public lands on. ..."
Source: Matt Brandt in bug 991664.


2. Less urgent and less important than 1 (above).

Medium term fix - in the 'new 29+ plugincheck'; track 'families' for
some plugins.

This bug is an example of a number of bugs where the 'underlying issue'
is the fact that there are some plugins, in widespread use, where there
are 'branch families'. I mean there may be a ESR and a 'current version'
or there may be 'version for Windows' and DIFFERENT version numbers used
for Linux.

Examples (already cited in this bug) include
"Adobe Acrobat 10.1.9 is marked as vulnerable on Windows Vista" bug 986588
the many versions of Flash, including ESR (documented at bug 956905 comment # 128).

Mozilla have no control over how 'plugin authors' (e.g. Adobe, Oracle etc)
use their 'version numbers'.  

The good news is that all of these bugs are on
"Tracker for Bugs and Feature Requests PluginCheck.current" bug 990857

3. Detail on the Version Numbers for Java and a possible cause
for this bug.

I said, in the first part of this post:
> It is better for a few Users of Plugincheck to see a message
> that their 'Java 8' is one of their "Unknown Plugins"
> than for the >99% of Users who have Java installed to have this
> 'false positive'.

I still hold this opinion.

However, in this actual case, if the record for Java version "11.0.2.132"
is removed from the 'plugincheck database', users of 'Java 8' might
see "Up to Date" (and not "Unknown").

This hypothesis is based on the following information.

In comment # 19 I asked:
> Has anybody got Java JDK 8 installed?
> What does about:plugins say (compare to comment # 3)?
> What does https://www.mozilla.org/en-US/plugincheck/ report for Java (compare to comment # 7)?

I wanted to see what 'version number' Oracle were using for 'Java 8'.

No one has posted an answer, in this bug, so I searched and found:

User "dff_gv" on 2014-03-20 in the thread
https://support.mozilla.org/en-US/questions/990988

has posted this screenshot
https://support.cdn.mozilla.net/media/uploads/images/2014-03-20-16-21-06-8eebd3.png

This shows Plugincheck detecting 'Java 8' as version "11.0.2.132" and
informing the User that this plugin is "Up to Date".

So, if 'Java 7 U 51' is 'detected by plugincheck as' (from comment # 20)

> Java(TM) Platform SE 7 U51
> Next Generation Java Plug-in 10.51.2 for Mozilla browsers

See also - comment # 4, where Catalin Varga has posted from about:plugins

> application/x-java-applet;jpi-version=1.7.0_51	Java&#153 Plug-in	
> application/x-java-bean;jpi-version=1.7.0_51	Java&#153 Plug-in	
> application/x-java-applet;deploy=10.51.2	Java&#153 Plug-in

So, it looks to me, as if Oracle are using
10.x.x.x for 'the Java 7 family' and
11.x.x.x for 'the Java 8 family'.

In my opinion, it would be good to treat these two as SEPARATE PLUGINS.

Oracle intend to support 'Java 7' until at least April 2015 (see 4 - below).

As more Users start to use 'Java 8' there WILL BE some
'latest' versions of the 'Java 7 family' and also OTHER
'latest' versions of the 'Java 8 family'.

As I write, 2014-04-10, I think plugincheck can only have ONE
'latest for Java' and IMO this should be 'the Java 7 version'
for the reasons already cited in this post.


4. Relevant references that are not in bugzilla:

"Java 7 on Firefox 28"
http://forums.mozillazine.org/viewtopic.php?f=38&t=2813021


Java 7 will be supported until at least April 2015, see

"Oracle Java SE Support Roadmap"
http://www.oracle.com/technetwork/java/javase/eol-135779.html

"... ...
Java SE 7 End of Public Updates Notice

After April 2015, Oracle will no longer post updates of Java SE 7 to its
public download sites. Existing Java SE 7 downloads already posted as of
April 2015 will remain accessible in the Java Archive on Oracle Technology
Network. Developers and end-users are encouraged to update to more recent
Java SE versions that remain available for public download. ..."

"Java version history"
https://en.wikipedia.org/wiki/Java_version_history

DJ-Leith
Flags: needinfo?(cbook)
not sure about this n-i but i guess the current problem is that its not clear what cause this plugincheck error for java see bug 959760, somehow the data from the database vs frontend are not the same
Flags: needinfo?(cbook)
Pretty Print version of the data from the URL posted in bug 959760 comment # 2
Line numbers have been added, to aid discussion in the comments below.
All 777 lines are in the attached Text file.
(In reply to Carsten Book [:Tomcat] from comment # 39)

> not sure about this n-i but i guess the current problem is that its not
> clear what cause this plugincheck error for java see bug 959760, somehow
> the data from the database vs frontend are not the same

Carsten, thanks for the link - I had not looked at (the closed) bug 959760.

Your screenshot in bug 959760 comment # 3

https://bug959760.bugzilla.mozilla.org/attachment.cgi?id=8404012

(from the frontend) clearly shows that the database has both
Java 7 (1.7.0.51) AKA "10.51.2.13" and
Java 8 (1.8.0.0)  AKA "11.0.2.132"

in bug 959760 comment # 2 Kohei Yoshino [:kohei] has posted a URL to the
'Plugin Finder Service' (PFS) that is part of the 'plugincheck service'.

One way to 'think of this data' is to imagine that it is like a
Report on known versions of Java plugins (stored in the 'plugincheck database')
that is going to be used by the 'plugincheck web site'.

Kohei could not find Java 7 U51.
Indeed, the only "u51" is a reference to the "vulnerability_url" of version 1.7.0.45
which was declared "vulnerable", by Oracle, when they released Java 7 U51.

> 'vulnerability_url': 'http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html'
> 'version': '1.7.0.45',
> 'detected_version': '1.7.0.45',

To make it easier to understand this data I have turned it into a text file,
with added line numbers - to aid reference.  There are 777 numbered lines
(see comment # 40).

Next is data for 3 plugins (lines 225-297).
This is data for Java 7 u25, Java 7 U21 and Java 7 U17 (descending version numbers).


> 225             {
> 226                 'id': '4',
> 227                 'pfs_id': 'java-runtime-environment',
> 228                 'name': 'Java Runtime Environment',
> 229                 'vendor': 'Sun Microsystems',
> 230                 'url': 'http://www.java.com/en/download/manual.jsp',
> 231                 'modified': '2014-03-20T19:21:54+00:00',
> 232                 'created': '2013-07-01T10:50:31+00:00',
> 233                 'plugin_id': '7',
> 234                 'os_id': '1',
> 235                 'platform_id': '4',
> 236                 'status': 'outdated',
> 237                 'version': '1.7.0.25',
> 238                 'detected_version': '1.7.0.25',
> 239                 'detection_type': '*',
> 240                 'os_name': '*',
> 241                 'app_id': '*',
> 242                 'app_release': '*',
> 243                 'app_version': '*',
> 244                 'locale': '*',
> 245                 'fetched': '2014-04-11T09:53:44-07:00',
> 246                 'relevance': 1
> 247             },
> 248             {
> 249                 'id': '4',
> 250                 'pfs_id': 'java-runtime-environment',
> 251                 'name': 'Java Runtime Environment',
> 252                 'vendor': 'Sun Microsystems',
> 253                 'url': 'http://www.java.com/en/download/manual.jsp',
> 254                 'modified': '2014-03-20T19:21:54+00:00',
> 255                 'created': '2013-07-01T10:50:31+00:00',
> 256                 'plugin_id': '7',
> 257                 'os_id': '1',
> 258                 'platform_id': '4',
> 259                 'status': 'vulnerable',
> 260                 'vulnerability_description': 'Vendor information',
> 261                 'vulnerability_url': 
'http://www.oracle.com/technetwork/topics/security/javacpujun2012-1515912.html',
> 262                 'version': '1.7.0.21',
> 263                 'detected_version': '1.7.0.21',
> 264                 'detection_type': '*',
> 265                 'os_name': '*',
> 266                 'app_id': '*',
> 267                 'app_release': '*',
> 268                 'app_version': '*',
> 269                 'locale': '*',
> 270                 'fetched': '2014-04-11T09:53:44-07:00',
> 271                 'relevance': 1
> 272             },
> 273             {
> 274                 'id': '4',
> 275                 'pfs_id': 'java-runtime-environment',
> 276                 'name': 'Java Runtime Environment',
> 277                 'vendor': 'Sun Microsystems',
> 278                 'url': 'http://www.java.com/en/download/manual.jsp',
> 279                 'modified': '2014-03-20T19:21:54+00:00',
> 280                 'created': '2013-03-06T18:16:07+00:00',
> 281                 'plugin_id': '7',
> 282                 'os_id': '1',
> 283                 'platform_id': '4',
> 284                 'status': 'vulnerable',
> 285                 'vulnerability_description': 'Vendor information',
> 286                 'vulnerability_url': 
'http://www.oracle.com/technetwork/topics/security/javacpuapr2013-1928497.html',
> 287                 'version': '1.7.0.17',
> 288                 'detected_version': '1.7.0.17',
> 289                 'detection_type': '*',
> 290                 'os_name': '*',
> 291                 'app_id': '*',
> 292                 'app_release': '*',
> 293                 'app_version': '*',
> 294                 'locale': '*',
> 295                 'fetched': '2014-04-11T09:53:44-07:00',
> 296                 'relevance': 1
> 297             },

Observations:

A. All 3 were 'fetched' (from the database) on "2014-04-11T09:53:44-07:00"

> 245                 'fetched': '2014-04-11T09:53:44-07:00',
> 270                 'fetched': '2014-04-11T09:53:44-07:00',
> 295                 'fetched': '2014-04-11T09:53:44-07:00',
All are also 'id': '4'.


B. All 3 were updated on "2014-03-20"; the date Carsten added Java 8 to the database.
From bug 985056 comment # 1:
> Carsten Book [:Tomcat] 2014-03-20 08:18:23 PDT
> 
> added the new version to plugincheck production and also 7u51 should be marked
> as latest (so not old/insecure)

From the above text file:
> 231                 'modified': '2014-03-20T19:21:54+00:00',
> 254                 'modified': '2014-03-20T19:21:54+00:00',
> 279                 'modified': '2014-03-20T19:21:54+00:00',


C. Each plugin version was 'added to the database' on different dates.
> 232                 'created': '2013-07-01T10:50:31+00:00',
> 255                 'created': '2013-07-01T10:50:31+00:00',
> 280                 'created': '2013-03-06T18:16:07+00:00',
In this example, two of the three at the same time.

D. All 3 are either
> 236                 'status': 'outdated',
or
> 259                 'status': 'vulnerable',
> 284                 'status': 'vulnerable',
None of these three examples are 'latest'.


Are ANY 'latest'?

Yes, see the top of the file.

>  10     'aliases': {
>  11         'regex': [
>  12             '.*Java Deployment Toolkit.*',
>  13             'Java Embedding Plugin .*',
>  14             'Java.* Platform SE.*',
>  15             'Java.* Plug-.*',
>  16             'Java Embedding Plugin .*',
>  17             'Java.* Platform SE.*',
>  18             '.*Java Deployment Toolkit.*',
>  19             'Java Embedding Plugin .*',
>  20             'Java.* Platform SE.*',
>  21             'Java.* Plug-.*'
>  22         ],
>  23         'literal': [
>  24             'Java Runtime Environment',
>  25             'Java Runtime Environment',
>  26             'Java Runtime Environment'
>  27         ]
>  28     },
>  29     'releases': {
>  30         'latest': {
>  31             'id': '4',
>  32             'pfs_id': 'java-runtime-environment',
>  33             'name': 'Java Runtime Environment',
>  34             'vendor': 'Sun Microsystems',
>  35             'url': 'http://www.java.com/en/download/manual.jsp',
>  36             'modified': '2014-03-20T19:21:53+00:00',
>  37             'created': '2014-03-20T19:21:53+00:00',
>  38             'plugin_id': '7',
>  39             'os_id': '1',
>  40             'platform_id': '4',
>  41             'status': 'latest',
>  42             'version': '1.8.0.0',
>  43             'detected_version': '1.8.0.0',
>  44             'detection_type': '*',
>  45             'os_name': '*',
>  46             'app_id': '*',
>  47             'app_release': '*',
>  48             'app_version': '*',
>  49             'locale': '*',
>  50             'fetched': '2014-04-11T09:53:44-07:00',
>  51             'relevance': 1
>  52         },
>  53         'others': [
>  54             {
>  55                 'id': '4',
>  56                 'pfs_id': 'java-runtime-environment',
>  57                 'name': 'Java Runtime Environment',
>  58                 'vendor': 'Sun Microsystems',
>  59                 'url': 'http://www.java.com/en/download/manual.jsp',
>  60                 'modified': '2014-03-20T19:21:53+00:00',
>  61                 'created': '2012-10-17T15:27:54+00:00',
>  62                 'plugin_id': '7',
>  63                 'os_id': '1',
>  64                 'platform_id': '4',
>  65                 'status': 'outdated',
>  66                 'version': '1.7.0.9',
>  67                 'detected_version': '1.7.0.9',
>  68                 'detection_type': '*',
>  69                 'os_name': '*',
>  70                 'app_id': '*',
>  71                 'app_release': '*',
>  72                 'app_version': '*',
>  73                 'locale': '*',
>  74                 'fetched': '2014-04-11T09:53:44-07:00',
>  75                 'relevance': 1
>  76             },
>  77             {
>  78                 'id': '4',
>  79                 'pfs_id': 'java-runtime-environment',
>  80 ... ...

Observations:

E. 
>  41             'status': 'latest',
>  42             'version': '1.8.0.0',
>  43             'detected_version': '1.8.0.0',
This is Java 8 (1.8.0.0) AKA "11.0.2.132".

This was 'detected' (as noted in comment # 38) as "11.0.2.132".
> User "dff_gv" on 2014-03-20 in the thread
> https://support.mozilla.org/en-US/questions/990988
> 
> has posted this screenshot
> https://support.cdn.mozilla.net/media/uploads/images/2014-03-20-16-21-06-8eebd3.png


F.
So, you might think the 'Java 8 (1.8.0.0)' data has 'been written on top 
of and replaced' the 'Java 7 u51' data (because we can't see any
'Java 7 u51' data) in this 'Report / output from the database'.

I don't think so: as I'll explain.

Notice the 'selection criteria' (lines 11-26) both a block of regex
>  11         'regex': [

and a block of literal
>  23         'literal': [

Are there ANY other 'latest'?
Yes, near the end:

> 743 {
> 744     'aliases': {
> 745         'literal': [
> 746             'IcedTea Java Web Browser Plugin'
> 747         ]
> 748     },
> 749     'releases': {
> 750         'latest': {
> 751             'id': '4',
> 752             'pfs_id': 'redhat-icetea-java',
> 753             'name': 'IcedTea Java Web Browser Plugin',
> 754             'vendor': 'Redhat',

The first 742 lines are 'sending data out of the database' to the
'plugincheck web site' about Java (from Sun / Oracle).

>  10     'aliases': {
>  11         'regex': [
>  12             '.*Java Deployment Toolkit.*',
>  13             'Java Embedding Plugin .*',

>  23         'literal': [
>  24             'Java Runtime Environment',

The last part, from line 743, is the IcedTea data:
> 745         'literal': [
> 746             'IcedTea Java Web Browser Plugin'


I think there is an algorithm that selects ONE latest
per 'selection (by aliases or literal)'.

so,
ONE latest for Java (from Sun / Oracle)
ONE latest for IcedTea Java Web Browser Plugin

Notice also, the others (the NOT the "latest"):
>  52         },
>  53         'others': [
Are below the ONE latest.

In bug 956905 Schalk posted (on his pastebin - the data tends to expire
after 30 days) many examples, from a local copy of the database, of 'data
for a particular plugin where there were many "latest" versions'. 

Some conclusions:

I think the 'Java 7 U51' data is still in the database
BUT
because 'all the Java from Sun / Oracle' data are selected
as 'one bucket of data', that match the aliases or literal criteria,
(lines 10 to 27) and only ONE (which has the 'highest version number')
is then deemed "latest" and 'sent to the plugincheck website'.
We have 'Java 7 U51' detected - a 'false positive' - *this bug*.

It is possible to have 'more than one type of plugin to do deal
with Java'.  You could have the IcedTea plugin.

Potentially, after a data review and possible editing of some 'fields in
the database' it would be possible to have the 'families of Java',
or e.g. ESR versions of Flash, that have been mentioned already.

DJ-Leith
Good news!

You may remember that Schalk Neethling [:espressive] in comment # 32 said:

> Thank you for filing this Catalin, and thank you for everyone's comments
> so far. This is something that is caused by the change in how plugin
> detection needs to work with regards to Fx 29+ so, first thing for me to
> do is to test this scenario against the new plugin check service under
> development, and confirm that I can reproduce the issue.
> 
> If I cannot reproduce this, then it means this bug will be resolved as
> soon as the new plugincheck is released. Because there are similar bugs,
> I am for the time being moving this to be tracked under bugs that effect
> the current plugin check, until I can confirm that this also will effect
> the new version.

Here is more information on the "new plugin check service under development".

"Plugin Status Service"
https://wiki.mozilla.org/Websites/Plugincheck/Plugin_Status_Service

This looks very promising.
The wiki explicitly references the situation in this bug (and the duplicates).

> The data structure requirement is as follows:
> 
>  *  We need to store information about the following releases:
>        - The latest release
>        - The latest safe release i.e. There might be a new release of
>           the plugin but, the version before is still safe and does not
>           suffer from vulnerabilities.  For example having Java 7u51
>           even though Java 8 has been released.
>        - Vulnerable 

The source code is here https://github.com/ossreleasefeed/plugin-status-service
If you follow the link to "Raw JSON of all plugins", in github,
you will see very similar data to the data discussed in comment # 41.

In particular, both the
>   "display_name": "Java Runtime Environment"
and the
>   "display_name": "IcedTea Java Web Browser Plugin"

are in the "Raw JSON of all plugins".

DJ-Leith
Re: wiki insert in Comment 42:
>  *  We need to store information about the following releases:
>        - The latest release
>        - The latest safe release i.e. There might be a new release of
>           the plugin but, the version before is still safe and does not
>           suffer from vulnerabilities.  For example having Java 7u51
>           even though Java 8 has been released.
>        - Vulnerable 

You may also want to store the latest safe release to cover the rare but possible case of a new version being installed, but then found to be vulnerable, yet without a fix.  The only safe alternative is a previous release.

Also consider this:  Presumably the upgrade was to fix a vulnerability.  Judgment call -- do you keep the current new problem, or downgrade to the previous devil you know?
(In reply to DJ-Leith from comment #42)
> Good news!

> > The data structure requirement is as follows:
> > 
> >  *  We need to store information about the following releases:
> >        - The latest release
> >        - The latest safe release i.e. There might be a new release of
> >           the plugin but, the version before is still safe and does not
> >           suffer from vulnerabilities.  For example having Java 7u51
> >           even though Java 8 has been released.
> >        - Vulnerable 

It does indeed sound good news, but I do have a question regarding clarification of the wording.

The *latest* release.
The *latest* safe release

I would read that to imply they are the same release.
The Newest release. 
The Newest safe release   

Because on the presumption that the latest release is safe isn't the Newest release always going to be the Newest safe release ?

I thought maybe the *earliest* safe release is what we would be interested in. In order to generate a list of, or range of  safe releases between and including the earliest safe release and the latest release. 



(In reply to Dan Pernokis from comment #43)
> Re: wiki insert in Comment 42:

> You may also want to store the latest safe release to cover the rare but
> possible case of a new version being installed, but then found to be
> vulnerable, yet without a fix.  The only safe alternative is a previous
> release.
> 

As has just happened with FlashPlayer 13 for some Mac s 
And note that a ESR version is not suitable for some older Mac s
< ATTENTION MAC CUSTOMERS - Flash Player 13 "Plugin Failure" Workaround  
<Apr 14, 2014 7:00 PM
<http://forums.adobe.com/thread/1447282
>We are aware that Macs created between 2006 and 2008 are currently running into problems using the latest release of Flash Player (version 13). 

In fact this incident adds an additional edge case that may be predictable with Flash Player not just OS compatibility but hardware compatibility may need to be considered by the user. So knowing what versions are safe not just a single safe version becomes very useful.
In reply to Comment 44:
> I thought maybe the *earliest* safe release is what we would be interested in. In order to 
> generate a list of, or range of safe releases between and including the earliest safe release 
> and the latest release. 

If Version 1.1 is safe, then it will forever be the "earliest" safe release.  I think we want the best most-recent feature-filled release (presumably latest) that runs safely (likely latest, but perhaps previous or second-previous, etc).

It does make sense to have a list of safe options.  Users want to know that they have an "outdated" (but safe) version with suitable upgrade options, or a "vulnerable" version with viable fixes -- and decide accordingly.  But we can't maintain a safe list back to the beginning of time.  Just as old Macs are having trouble with the new Flash 13, so an old reliable "safe" product may at a future date be vulnerable under Windows 2016, OSXV, or Firefox 50.
(In reply to Dan Pernokis from comment #43)
> Re: wiki insert in Comment 42:
> >  *  We need to store information about the following releases:
> >        - The latest release
> >        - The latest safe release i.e. There might be a new release of
> >           the plugin but, the version before is still safe and does not
> >           suffer from vulnerabilities.  For example having Java 7u51
> >           even though Java 8 has been released.
> >        - Vulnerable 
> 
> You may also want to store the latest safe release to cover the rare but
> possible case of a new version being installed, but then found to be
> vulnerable, yet without a fix.  The only safe alternative is a previous
> release.
> 
> Also consider this:  Presumably the upgrade was to fix a vulnerability. 
> Judgment call -- do you keep the current new problem, or downgrade to the
> previous devil you know?

I think the solution to such a conundrum is to keep the 'average' User at the older version (unless the risk is judged (by us) to be far more extreme) and have the Browser issue a PopUp to warn that their version of Java is vulnerable (and that a "Fix" is not yet available).

That exposes the User to a vulnerability (if they accept the risk) that is sooner to be fixed and more likely to be blocked by their Internet Security Software (assuming they have any) on a URL by URL basis (as mine does).


If the newer version of Java (or any other PlugIn for that matter) still has some discovered vulnerability that WE ought to warn our Users about then we can issue a PopUp in any event. 

Some responsibility must be borne by the User's Internet Security Software. We write and give away (for free) a "Browser", not a babysitter -- EG: our Browser does not scan downloads for Viruses, nor should it.


As for us, (not the 'average' User), we need to upgrade to the newest version of each PlugIn so we can try to stay at the bleeding edge and have things fixed for others as they chime in (upgrade); unless to do so places US at too great a peril.

Such a system may be best suited for Aurora were we want to provide some level of 'Guarantee' of stability / safety / speed (whereas with Nightly the journey may be more fraught with peril.


Having said that we do not "babysit", I do not see that implementing a Sandbox for our PlugIns would be out of the question. All files created by any PlugIn could be Sandboxed (and deleted, never executed). 

The only way that could annoy would be IF someone went to a Site that offered a "Java Bulk Downloader" (and the User had to confirm that they wanted to "Save" the downloaded Files outside the Sandbox). Saving such Files is not too much of an issue (and not "our" problem) as long as we (our Browser) do not "execute" said Files.
Assignee: nobody → schalk.neethling.bugs
Severity: normal → critical
Flags: needinfo?(schalk.neethling.bugs)
Priority: -- → P1
We are in the process of rolling this out to production with an estimated ETA of today (9 May 2014)
Depends on: 1003148
Depends on: 1008102
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/54f2aef2a835ac39f773877b824a5289689f2c8f
Fix Bug 985968, ensure all valid versions of java are shown as up to date

https://github.com/mozilla/bedrock/commit/05439db993c77f33564a51fb040f53182a106816
Merge pull request #1987 from ossreleasefeed/bug985968-plugincheck-incorrectly-displays-java7-as-vulnerable

Bug985968 plugincheck incorrectly displays java7 as vulnerable
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
I just updated FF to 29.0.1 (Release Channel) and presumably ran the new plugin check.  Java 7 no longer shows as outdated (has green up-to-date tag).  Thanks for everyone's hard work on this getting it out.

But now the STATUS column shows "10.55.2.14" for both the Java Plugin ("Java(TM) Platform SE 7 U55 // Next Generation Java Plug-in 10.55.2 for Mozilla browsers") and the Java Deployment Toolkit ("Java Deployment Toolkit 7.0.550.14 // NPRuntime Script Plug-in Library for Java(TM) Deploy").  Note the platform plugin description does not have the ".14" suffix on the version -- it just says "10.55.2".

Meanwhile, the ADD-ONs MANAGER page shows the toolkit version as a continuous string: 
"7.0.550.14 10.55.2.14"
...and then warns the Deployment Toolkit is blocked because it is vulnerable (which I know is a different story).  Very confusing -- am I up to date or not?
Add to my Comment 50...
So where does the "10" part come from in the version, if it is only Java 7?
Verified.

just filed bug 1008387 for the toolkit in add-ons manager.
Status: RESOLVED → VERIFIED
(In reply to Dan Pernokis from comment #51)
> Add to my Comment 50...
> So where does the "10" part come from in the version, if it is only Java 7?

Windows 7 Home Premium (x64)
SeaMonkey/2.26
Java 7 u55

SeaMonkey's [Help > About Plugins] shows "Version: 10.55.2.13".  

SeaMonkey's [Tools > Addons Manager > Plugins] shows "Java(TM) Platform SE 7 U55 10.55.2.13". 

Windows' [Settings > Control Panel > Java] shows "Platform 1.7" and "Product 1.7.0_55".  

The the properties of file java.exe shows both file and product versions as 7.0.550.13.  The same is true of the installer file jre-7u55-windows-i586.exe.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: