Closed Bug 938698 Opened 11 years ago Closed 11 years ago

Java 7u45 is CTP blocked for some versions

Categories

(Toolkit :: Blocklist Policy Requests, defect)

Product:
Toolkit
Component:
Blocklist Policy Requests
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: u279076, Unassigned)

References

Details

In bug 914690 we pushed a block for Java 7u45 to Firefox 24+ which was later reverted in bug 914690 comment 80. However since yesterday it seems this block is being applied for certain Firefox versions. Currently Java 7u45 defaults to "Ask to Activate" for Firefox 25.0 and 24.1.1 but is "Always Activate" for Firefox 25.0.1. This has caused our Mozmill tests to fail for 24.1.1esr (bug 938029). It's odd because this was working fine when we tested Firefox 25.0 a couple weeks ago. I'm not sure why it's failing now. Steps to Reproduce: 1. Install Firefox 2. Install Java 7u45 3. Start Firefox with a new profile 4. Open the Addons Manager 5. Display the Plugins pane Result: Java 7u45 is marked vulnerable and is set to "Ask to Activate". Note that this is before doing any blocklist pings. We're doing some testing to identify what other versions might be affected.
Depends on: 914690
Blocks: 938029
Upon further investigation I'm seeing the following in my Firefox 25.0 installation blocklist file: > <pluginItem blockID="p463"> > <match name="name" exp="Java\(TM\) Platform SE 7 U45(\s[^\d\._U]|$)"/> > <match name="filename" exp="npjp2\.dll"/> > <versionRange severity="0" vulnerabilitystatus="2"> > <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"> > <versionRange minVersion="24.0" maxVersion="*"/> > </targetApplication> > </versionRange> > </pluginItem> This item does not exist in Firefox 25.0.1's default blocklist file.
No longer blocks: 938029
Affects default install of FF26, 27 and 28 also.
It sounds like Firefox 25.0 shipped with the block we eventually reverted in its default blocklist, so the latest Java plugin will be blocked until the blocklist is reloaded from the server.
Sorry for the bugspam, I didn't mean to unblock bug 938029.
Blocks: 938029
(In reply to Jorge Villalobos [:jorgev] from comment #3) > It sounds like Firefox 25.0 shipped with the block we eventually reverted in > its default blocklist, so the latest Java plugin will be blocked until the > blocklist is reloaded from the server. But wouldn't that mean that all versions shipped after 25.0 would have this block? Why would 25.0 have p463 in it's default blocklist but 25.0.1 does not? Similarly why would 24.0esr have the blocklist but 24.1.1esr does not? For the record I can reproduce this block in Firefox 25.0 and 24.1.1esr but not in Firefox 24.0, 25.0.1, 24.0esr, and 26.0b4.
(In reply to Anthony Hughes, QA Mentor (:ashughes) [On vacation, Nov 15-Dec 3] from comment #5) > Similarly why would 24.0esr have the blocklist but 24.1.1esr does not? Sorry, I worded this backward -- why would 24.1.1esr have the block but 24.0esr does not?
The following shows the state of the shipped blocklist on Windows: * Firefox 24.0: p463 NOT present * Firefox 24.0esr: p463 NOT present * Firefox 24.1.0esr: p463 present * Firefox 24.1.1esr: p463 present * Firefox 25.0: p463 present * Firefox 25.0.1: p463 NOT present * Firefox 26.0b4: p463 NOT present * Firefox 27.0a2: p463 NOT present * Firefox 28.0a1: p463 NOT present
I get the same results as comment 7 for Mac (p462) and Linux (p464), though it would seem that contradicts what Matt was seeing in comment 2.
(In reply to Anthony Hughes, QA Mentor (:ashughes) [On vacation, Nov 15-Dec 3] from comment #8) > I get the same results as comment 7 for Mac (p462) and Linux (p464), though > it would seem that contradicts what Matt was seeing in comment 2. Note that this was based on the blocklist.xml shipped in the exe, not sure if it's different in the .dmg or tar.bz2 files.
Linux x86_64 tarball: * Firefox 24.0: p464 NOT present * Firefox 24.0esr: p464 NOT present * Firefox 24.1.0esr: p464 present * Firefox 24.1.1esr: p464 present * Firefox 25.0: p464 present * Firefox 25.0.1: p464 NOT present * Firefox 26.0b4: p464 NOT present * Firefox 27.0a2: p464 NOT present * Firefox 28.0a1: p464 NOT present
For the record here is the full set of blocks. Mac OSX: > <pluginItem blockID="p462"> > <match name="filename" exp="JavaAppletPlugin\.plugin"/> > <versionRange minVersion="Java 7 Update 45" maxVersion="Java 7 Update 45" severity="0" vulnerabilitystatus="2"> > <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"> > <versionRange minVersion="24.0" maxVersion="*"/> > </targetApplication> > </versionRange> > </pluginItem> Windows: > <pluginItem blockID="p463"> > <match name="name" exp="Java\(TM\) Platform SE 7 U45(\s[^\d\._U]|$)"/> > <match name="filename" exp="npjp2\.dll"/> > <versionRange severity="0" vulnerabilitystatus="2"> > <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"> > <versionRange minVersion="24.0" maxVersion="*"/> > </targetApplication> > </versionRange> > </pluginItem> Linux: > <pluginItem blockID="p464"> > <match name="name" exp="Java(\(TM\))? Plug-in 10\.45(\.[0-9]+)?([^\d\._]|$)"/> > <match name="filename" exp="libnpjp2\.so"/> > <versionRange severity="0" vulnerabilitystatus="2"> > <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"> > <versionRange minVersion="24.0" maxVersion="*"/> > </targetApplication> > </versionRange> > </pluginItem>
(In reply to Anthony Hughes, QA Mentor (:ashughes) [On vacation, Nov 15-Dec 3] from comment #5) > (In reply to Jorge Villalobos [:jorgev] from comment #3) > > It sounds like Firefox 25.0 shipped with the block we eventually reverted in > > its default blocklist, so the latest Java plugin will be blocked until the > > blocklist is reloaded from the server. > > But wouldn't that mean that all versions shipped after 25.0 would have this > block? I suppose that when Firefox is built we pull the latest version of the blocklist and bundle it with the installer. I'm not involved in that process, though. > Why would 25.0 have p463 in it's default blocklist but 25.0.1 does not? > Similarly why would 24.0esr have the blocklist but 24.1.1esr does not? I would (again) suppose that those versions were built after we reverted the blocks.
(In reply to Matt Wobensmith from comment #2) > Affects default install of FF26, 27 and 28 also. These builds are "Ask to Activate" but do not have the block in blocklist.xml because CTP is on by default in 26+. So the real issue is is that current 24esr contains a blocklist that we were supposed to have pulled back. This could be an issue of concern for enterprises as we turn on auto-update for 17esr -> 24.2.0esr in the coming weeks.
OK, so we can confirm that the latest 24.1.1esr blocklist.xml contains this entry, which effectively will block the latest Java by default for ESR users. This is not a regression, as 24.1.0esr has the same problem. It was not caught by our automation, but that's a different issue. So the question is: do we fix this blocklist file and respin 24.1.1esr? Or do we ship as-is?
(In reply to Matt Wobensmith from comment #14) > So the question is: do we fix this blocklist file and respin 24.1.1esr? Or > do we ship as-is? This is pretty important for ESR, so I think it's serious enough to warrant a respin. The call is for the Release Managers to make.
Flags: needinfo?(release-mgmt)
This has reproduced in 25.0.0 and 24.1.0 without any complaints from users or deployments. Matt is going to test to make sure this is resolved upon first blocklist ping, in which case we'll just live with this regression. Even still, I'm leaning towards wontfix for 24.1.1.
Flags: needinfo?(release-mgmt) → needinfo?(mwobensmith)
It appears that the blocklist ping and subsequent retrieval of a new blocklist resolves the problem. This probably explains why FF25.0 and 24.1.0esr users have not complained. Their default update interval is one day, so any issues they may have resolve after that time period has elapsed. So, perhaps then, this isn't too much of an issue.
Flags: needinfo?(mwobensmith)
Closing as WONTFIX then.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Thanks for helping test this Matt. No respin then, and we'll stick to comment #16 on this bug.
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.