634639 - block old XPCOM java plugin npjpi160_XX.dll

Status: RESOLVED FIXED

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Josh Aas]

We're still trying to load the old XPCOM Java plugin in some cases, see bug 633463. We don't ever want it to load in Firefox 3.6 or higher because we don't support XPCOM plugins any more. I'm not sure what the best way to block this would be, but maybe we can do it by dll name - "npjpi160_XX.dll", where "XX" stands in for digits like "08".

Comment 1

[Benjamin Smedberg]

I guess there's not a method to just query the plugin to see if it's the old-style Java directly? They don't export some special function?

Doesn't this affect npjpi150* also?

Comment 2

[Josh Aas]

(In reply to comment #1)
> I guess there's not a method to just query the plugin to see if it's the
> old-style Java directly? They don't export some special function?

The old-style plugin has a different dll name than the new one so I don't see why we'd need to query the plugin. I don't know how XPCOM plugins are built so I don't know if they export something we can detect.

We could hard-code against this plugin based on "npjpi" as the prefix on the dll, but this sounds like the task that blocklisting was made for.

> Doesn't this affect npjpi150* also?

I wasn't able to find any crash reports from 3.6 or 4 from the past two weeks involving npjpi150*, I say we skip it unless we have evidence that it is a problem.

Comment 3

[Benjamin Smedberg]

Bug 633466 indicates a significant spike in NPJPI150* crashes, just like npjpi160

Comment 4

[Josh Aas]

Ah, my search was foiled by the case change - was searching for "npjpi150", not "NPJPI150". In that case lets include "NPJPI150*".

Comment 5

[Johnathan Nightingale [:johnath]]

Per bsmedberg on the driver call, assigning to josh

Comment 6

[Benjamin Smedberg]

Josh, were you planning on doing this with the AMO blocklisting bits, or in-code? I'm not sure AMO blocklisting can deal with multiple plugin names/versions like this, so it might be better to just refuse to load plugins with these names in-code.

Comment 7

[LegNeato]

I think we can do this with the AMO blocklist. Looks like We can use regular expressions for both the dll name and the plugin name (see https://wiki.mozilla.org/Extension_Blocklisting:Code_Design)

Comment 8

[LegNeato]

Attachment: Possible blocklist SQL

Attaching (untested) possible blocklist SQL. We can probably get more specific if we want (regex on the name, guid, etc) but this should be the minimum data required to not load the dll.

Comment 9

[LegNeato]

Attachment: Possible blocklist SQL for 16 and 15

Whoops, see we need to block 15 as well as 16

Comment 10

[Justin Scott [:fligtar]]

We have an admin tool to do blocks and don't need SQL anymore, so feel free to just post the relevant regexes in a comment :)

Comment 11

[LegNeato]

Ooooh, fancy schamncy.

Versions: 3.6 -> *
Filename: npjpi1[56]0_[0-9]+[.]dll

Comment 12

[LegNeato]

And by versions I mean "Firefox versions the block needs to apply to"

Comment 13

[Justin Scott [:fligtar]]

(In reply to comment #11)
> Ooooh, fancy schamncy.
> 
> Versions: 3.6 -> *

Should this be 3.6a1pre or do the crashes only affect 3.6 stable?

> Filename: npjpi1[56]0_[0-9]+[.]dll

Should [.] be \. ?

Comment 14

[LegNeato]

(In reply to comment #13)
> Should this be 3.6a1pre or do the crashes only affect 3.6 stable?

Can't hurt to make it 3.6a1pre I guess

> Should [.] be \. ?

It can be. It looks to be done the other way in the blocklist sql I based mine on to sidestep the sql escaping issues when running the query straight against the database. If the tool takes care of proper escaping (which I am sure it does) we can use \.

Comment 15

[Josh Aas]

Comment on attachment 512981 [details]
Possible blocklist SQL for 16 and 15

Looks good, aside from the stuff you and Justin already discussed.

Comment 16

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

--> fliggy, I think?

Comment 17

[LegNeato]

Yep, don't think I have access to the admin interface. Once it's in I can get RelEng to trigger the auto-sync so the updated list lands on m-c as well

Comment 18

[Justin Scott [:fligtar]]

Is this a soft or hard block?

Comment 19

[Benjamin Smedberg]

hard

Comment 20

[Justin Scott [:fligtar]]

Ok. This is up on staging as
  <pluginItem>
    <match name="filename" exp="npjpi1[56]0_[0-9]+\.dll"/>
    <versionRange>
      <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
        <versionRange minVersion="3.6a1pre" maxVersion="*"/>
      </targetApplication>
    </versionRange>
  </pluginItem>

Christian, please test (https://wiki.mozilla.org/Blocklisting/Testing) and if all is well you can file the bug to update the blocklist page. Once that's done I can push it.

Comment 21

[LegNeato]

Is the blocking case-insensitive? If not we should actually do:

[Nn][Pp][Jj][Pp][Ii]1[56]0_[0-9]+\.[Dd][Ll][Ll]

Comment 22

[LegNeato]

Bug 634932 is the website updating and bug 634931 is the manual sync so the m-c blocklist matches what is on the webservice

Comment 23

[LegNeato]

I'm testing this now...

Comment 24

[LegNeato]

I'm not seeing the block (still stays loaded even after a restart). The DLL name I have is all caps...is comment 21 the reason for the block not working? FWIW, I downloaded and installed http://www.oldapps.com/java.php?old_java=52?download on windows 7

Comment 25

[LegNeato]

This is what I got when I installed the above:

File: NPJPI150_18.dll
Version: 5.0.180.2
Name: Java Plug-in 1.5.0_18 for Netscape Navigator (DLL Helper)

Comment 26

[Justin Scott [:fligtar]]

Updated staging to use the new regex. does that fix it?

Comment 27

[LegNeato]

Attachment: Block Screenshot

Yep, that worked! Confirmed it gets blocked on minefield and 3.6.13

Comment 28

[LegNeato]

Over to fligtar to push live.

Comment 29

[LegNeato]

(I think this can go live before the website changes fwiw. Not ideal, but this is the most important bit to get in and the website can be updated after it lands)

Comment 30

[Justin Scott [:fligtar]]

Too many people click Learn More on blocks to not update the website before we block something.

Comment 31

[LegNeato]

Ok, though for nightlies it doesn't really matter and we are probably a couple of days before a beta build and a couple more before the actual release. My point was that it's likely 4 days or so until our beta audience would even be looking for the page...we can land this, get it on mozilla-central (bug 634931), and then work on the website.

I'll work on the website copy now so the point is moot.

Comment 32

[LegNeato]

Website changes (bug 634932) are done and live. Let's push this unless there is additional QA needed.

Comment 33

[Justin Scott [:fligtar]]

Blocked in production.

Comment 34

[F C]

Would be nice to propose a working alternative, if available, or mention that there is none. As far as I know, there's no Java 7 available yet. GNU is still far from being a serious replacement.

Comment 35

[Benjamin Smedberg]

Java 6 is the working alternative. This is just about the old Java plugin technology, the new one works fine.

Comment 36

[F C]

Benjamin, am I missing something? Maybe it's not clear to me if both "old" and "new" style are always available or when the new is available, but from the comment history it seems that both 5 and 6 are being blocked:

--
Josh Aas (Mozilla Corporation) 2011-02-16 09:53:58 PST

(...) I'm not sure what the best way to block this
would be, but maybe we can do it by dll name - "npjpi160_XX.dll", where "XX"
stands in for digits like "08".
--

I see 160 there, which to me would mean Java 6. Then:

--
Justin Scott [:fligtar] 2011-02-17 08:53:34 PST

Ok. This is up on staging as
  <pluginItem>
    <match name="filename" exp="npjpi1[56]0_[0-9]+\.dll"/>
    <versionRange>
      <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
        <versionRange minVersion="3.6a1pre" maxVersion="*"/>
      </targetApplication>
    </versionRange>
  </pluginItem>
--

"6" seems to be included in the regex. Same rationale as above.

So what am I missing?

Comment 37

[Matthias Versen [:Matti]]

>So what am I missing?
You are missing that only the XPCOM plugin from JRE1.5 and JRE1.6 are blocked but not the new NPAPI plugin in JRE1.6U10 or later.

from my about:plugins
    File: npjp2.dll
    Version: 6.0.240.7
    Next Generation Java Plug-in 1.6.0_24 for Mozilla browsers

Comment 38

[Josh Aas]

5 and 6 isn't the distinction between new and old here. Multiple plugins ship with versions of Java higher than SE6U10 or so. Even the latest version, SE6U24 I think, ships with and old OJI plugin prefixed with "npjpi" and the newer NPAPI plugin, which is prefixed with "npjp2" or something like that.

Comment 39

[chuck_norris000]

why my java enviroment uninstalled???? when i wanted to use screencast-o-matic, it says missing plug-in????