497423 - [1.9.2+] blocklist all versions of the Java plugin prior to Java SE 6 Update 14

Status: RESOLVED WORKSFORME

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Josh Aas]

Java SE 6 Update 14 includes the first Java plugin that does not use any XPCOM. Since we intend to remove all XPCOM plugin support in Gecko 1.9.2 we should blocklist all prior versions of the Java plugin in Gecko 1.9.2+.

Comment 1

[Michael Morgan [:morgamic]]

Is Sun on board with this?  All good to go?

Comment 2

[Josh Aas]

I think we're OK to do this but I'd like to have jst agree with me here before we do it.

SE 6 Update 10 was the first release with NPAPI support, but since it was the first release it was kind of buggy. SE 6 Update 14 had some big fixes and that I why I suggested we make it the minimum. SE 6 Update 16 is the latest version.

Since 1.9.2 can't load non-NPAPI plugins we should definitely blocklist, and I think Update 14 is the place to do it but we could technically blocklist up to only 11 or 12.

Comment 3

[Johnny Stenback (:jst)]

Yeah, nothing older than SE 6 works with 1.9.2, and given that recent minor updates made a big difference here I think it makes sense to block all older ones in this case.

Comment 4

[Wil Clouser [:clouserw]]

-> morgamic for the block

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

(well, me for marking it blocking, but morgamic for adding it to the blocklist)

Josh: have we *told* Sun we're going to do this?

Comment 6

[Josh Aas]

Yes

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Then let's do it?

Comment 8

[Tim Meader]

Perhaps this is a stupid question, but if a restriction is going to be put in place anyway, why not force the user to use the latest (as of implementation) version of Java/JRE available? Especially since update 17 had security fixes over 15 (which already had security fixes over 14). Just seems that if it's going to inconvenience the user in the first place... why not make sure they're getting started with the most secure version?

Comment 9

[Josh Aas]

"if it's going to inconvenience the user in the first place"

If you already have >= 14, you won't be inconvenienced by this in the first place. Sometimes deployments are not up to date with releases for various reasons.

Comment 10

[Michael Morgan [:morgamic]]

So, how do I single out this plugin using description/filename/name?

Comment 11

[Josh Aas]

We want this block on Windows and Linux only, for any plugin that has these file names and corresponding plugin names. For some versions I'm making pattern assumptions.

Windows file name: npjp2.dll

Windows plugin names:
Java(TM) Platform SE 6 U10
Java(TM) Platform SE 6 U11
Java(TM) Platform SE 6 U12
Java(TM) Platform SE 6 U13

Linux file name: libnpjp2.so

Linux plugin names:
Java(TM) Plug-in 1.6.0_10
Java(TM) Plug-in 1.6.0_11
Java(TM) Plug-in 1.6.0_12
Java(TM) Plug-in 1.6.0_13

Comment 12

[Josh Aas]

To be extra clear - only block plugins that match both criteria, don't block all plugins with those file names.

Comment 13

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Is the plugin naming pattern consistent prior to Update 10?

Comment 14

[Josh Aas]

I don't know, the plugin we're targeting here (NPAPI, not XPCOM, Java) was introduced in Update 10. There are no plugins with those file names prior to Update 10.

Comment 15

[d]

This is blocking Firefox 3.6 but isn't yet resolved. Is there an issue, or has it been fixed but not reflected by the status in this bug?

Comment 16

[Jorge Villalobos [:jorgev] (he/him)]

This was superseded by other blocks. See https://wiki.mozilla.org/Blocklisting/PluginBlocks