Description of problem: When trying to listen to an ogg file for the first time, two dialogue boxes pop up and scare the user. Are these really necessary? Version-Release number of selected component (if applicable): Version : 1.6.0.0 Release : 0.23.b12.fc10 How reproducible: Unknown. It only happened once, and they haven't come back to harrass me since. Steps to Reproduce: 1. Install F10 beta 2. Update to rawhide 3. Visit http://commons.wikimedia.org/wiki/Image:Tromboon-sample.ogg and receive annoying/scary dialogue boxes Actual results: My browser wants me to make a decision I shouldn't have to care about. Expected results: Sane defaults so I don't have to think about a temporary directory for jnlp files (whatever those are). The security warning is annoying too, but I can _kinda_ see both sides of that argument (although in my opinion, it should go away too, since most people are realistically just going to click "ok" to make the dialogue box go away, thus negating any actual increaes in security). Additional info:
Created attachment 320778 [details] netx dialogue box
Created attachment 320779 [details] security dialogue box
I saw Lubomir committed a fix for this to EPEL-5. Can the change be used in Fedora as well?
(In reply to comment #3) > I saw Lubomir committed a fix for this to EPEL-5. Can the change be used in > Fedora as well? Andrew: I did not build it yet, and I won't in its current shape, so the short answer is "not yet". I simply replaced default of /tmp with hardwired java.io.tmpdir, however it turns out not to be a good idea, since it creates predictable names there, which is unsafe. A better fix would be to use a path in user's home directory. ~/.netx already exists and maybe we can use it. What do you think?
(In reply to comment #4) > I simply replaced default of /tmp with hardwired java.io.tmpdir, however it > turns out not to be a good idea, since it creates predictable names there, > which is unsafe. Yeah. > A better fix would be to use a path in user's home directory. ~/.netx already > exists and maybe we can use it. What do you think? Sounds good to me, but I'm no expert in this area.
I changed it to ~/.netx http://cvs.fedoraproject.org/viewvc/rpms/java-1.6.0-openjdk/EL-5/java-1.6.0-openjdk-netxtmp.patch?revision=1.2
The jar files used by netx are temporary files and imho belong into /tmp (easier housekeeping, etc.). But this may be only my opinion :) The default permission for the cache directory is set to "drwx------", so the "predictable names" problem does not really exist. But there is currently a more severe bug when multiple users are starting javaws on the same machine: - First user (alicia) opens a jnlp file and chooses /tmp , her jnlp jars are downloaded and executed by netx, file permissions for /tmp/cache are set to alicia - Second user (oscar) on the machine also starts a jnlp file (choosing /tmp). Oscar gets a "permission denied" on /tmp/cache due to tight directory permissions and umask settings for user alicia. Adding an additional level to the cache directory structure such as /tmp/netxcache/${user} may help to the goals of keeping the jar files private (due to umask), keeping temporary files in /tmp, and giving multiple users the ability using netx. This would mean that alicia gets her files stored in /tmp/netxcache/alicia (private to her due to umask) and oscar gets his files from /tmp/netxcache/oscar. Having this default naming policy for the cache location would also make the security dialogue box superfluous for most cases, as advanced users may still like to adjust this setting in their ~/.netxrc .
(In reply to comment #7) > The default permission for the cache directory is set to "drwx------", so the > "predictable names" problem does not really exist. Does that mean that a malicious user can not create that directory with a different mode prior to victim being able to create it? > Adding an additional level to the cache directory structure such as > /tmp/netxcache/${user} may help to the goals of keeping the jar files private > (due to umask), keeping temporary files in /tmp, and giving multiple users the > ability using netx. This does not make sense to me. What mode would you expect /tmp/netxcache to have?
This dialog no longer appears with the new plugin (upstream release 1.3.1+ and current rawhide). Cache directory is now $HOME/.icedteaplugin/cache , so it is automatically separated per user. I think that the EPEL package should remove the patch from rpm and update to the latest upstream to get the fix for this issue.
Can we close this? Marc Schoenefeld suggested (on irc) that we add a networking check (to determine the origin. - "We should check the code that verifies the origin of the jar with the network destination it tries to reach" Opinions?
(In reply to comment #9) > This dialog no longer appears with the new plugin (upstream release 1.3.1+ and > current rawhide). Cache directory is now $HOME/.icedteaplugin/cache , so it is > automatically separated per user. I do not think this is sufficient. What if user uses "javaws" from command line, or clicks a link to ".jnlp" file?
Yeah, the problem will still exist for users running it via commandline. My response was directed toward the original bug report, which is against the plugin.
Back to the original bug: Hi Deepapk, the "null" box still pops up with "2b12.fc10", looks like a failing origin check within openjdk's netx plugin, as both files, player and ogg file come from the same origin host, no security check box (the second "null" box) should pop up at all. Starting the applet via Sun's Browser Plugin plays the ogg file without boxes or complaints (JDK 6 on RHEL5): > network: Downloading resource: http://upload.wikimedia.org/jars/cortado.jar > Content-Length: 201,412 > Content-Encoding: null > network: Wrote URL http://upload.wikimedia.org/jars/cortado.jar to File /home/xyz/.java/deployment/cache/6.0/59/acb917b-77562de6-temp > network: No certificate info for unsigned JAR file: http://upload.wikimedia.org/jars/cortado.jar > [INFO] param "url" has string value "http://upload.wikimedia.org/wikipedia/commons/a/a9/Tromboon-sample.ogg" Please verify the origin check within the netx code. It looks like the host of the embedding page (commons.w.o) instead of the host the applet is downloaded from (upload.w.o) is mistakenly used to compare the origin.
Ah, you are referring to the permission dialog that appears on that site. Yes, I just saw that too :/ I will look into it today.
Created attachment 321990 [details] New warning dialog Hi Marc, I have updated the code to: 1. Get rid of the "null" fields, and show the proper origin 2. Bypass check when connecting to same origin Please see attached screenshot for what it looks like now (it will not appear on that wikimedia link btw.. the attached dialog is just a sample).
This bug has been triaged
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Caching for netx fixed upstream. will be in the next release.
java-1.6.0-openjdk-1.6.0.0-18.b16.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-18.b16.fc10
java-1.6.0-openjdk-1.6.0.0-22.b16.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-22.b16.fc11
java-1.6.0-openjdk-1.6.0.0-22.b16.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
java-1.6.0-openjdk-1.6.0.0-18.b16.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.