On Mac OS X 10.9 signed Java Web Start applications are blocked by default with the message:
"application.jnlp" can't be opened because it is from an unidentified developer.
I know it's possible to weaken the security checks to allow any application to run, but that requires a manual intervention of the end user.
Is it possible to "sign" a Java Web Start application such that it is recognized as originating from an identified developer?
Thank you
In the latest OSX releases, Apple has changed it's security model to only support applications from the Mac App Store and identified developers. In most cases, this prohibits jnlp/java-web-start applications from launching.
If this is a trusted application, you may override these settings by updating your system settings as follows:
System Preferences -> Security & Privacy -> (Unlock Window) -> Allow apps downloaded from: (Select Anywhere)
In some cases you may need to update your Java Security preferences too
System Preferences -> Java -> Security -> (Select Medium)
Be careful when adjusting these. These settings will open you up to popular attack vectors where an attacker can exploit vulnerabilities within the java runtime (Java 0 days).
Here is a related post. It doesn't appear to be possible to bypass the security, Allow All, workaround.
OS X 10.8 Gatekeeper and Java applets
From Apple Tech Support in the post above.
Unidentified developer" means a source other than the Mac App Store
or a Developer ID-identified developer. Note that Java applets cannot
participate in the Developer ID program.
I am considering building a native app and use a custom web protocol instead similar to skype where you see skype:// in the URI. It doesn't seem like Apple will change their stance on java applets in the near future. It will most likely become more restricted and eventually just disabled like flash on iOS.
Apple does appear to support signing of webstart -- but not directly. You have to bundle it in an archive. See the note at the bottom of this page:
You can use the codesign utility to sign the JNLP file, which will attach the code signature to the JNLP file as extended attributes. To preserve these attributes, package the JNLP file in a ZIP, XIP, or DMG file. Be careful using the ZIP format, as some third-party tools might not capture the required extended attributes correctly.
Also note that XIP isn't supported for non-Apple developers anymore:
Important: Starting with macOS Sierra, only XIP archives signed by Apple will be expanded. Developers who have been using XIP archives will need to move to using signed installer packages or disk images.
The answers to How to sign (dynamic) JNLP files for OSX and Gatekeeper address this question, just ignore the 'dynamic' aspect.
You can codesign -f -s "Developer ID Application: " application.jnlp but the HFS resource won't transfer with the file over the web.
Until Oracle works out a solution, if they ever do, addressing JNLP/Web Start it looks like we have to figure out a work-around that starts us down the path to creating a Mac app bundle.
This seems to have changed in OS X 10.10. Now after going to System Preferences -> Security & Privacy -> (Unlock Window) -> Allow apps downloaded from: (Select Anywhere) (after trying to run the .jnlp file) you'll see an option to "Run anyway".
Sadly Apple has removed the Anywhere option under System Preferences -> Security & Privacy in macOS Big Sur versions.
Below is a very simple way on How to override MacOS security settings for unsigned jnlp files when you get the following message:
"file-name.jnlp" cannot be opened because it is from an unidentified developer. macOS cannot verify that this app is free from malware.
Follow the steps below to override the system security settings:
ensure the jnlp file has been downloaded (normally in Downloads folder)
find the file in Finder and use Control + click and then Open
you should get slightly different dialog with the Open button allowing you to override the system security settings and execute the file.
Reference
Also you may need to download OpenWebStart for macOS
Related
We would like to brand a piece of software based on which customer's website it is downloaded from. E.g. by showing the customer's logo etc. All we need is an ID, the software can handle the rest of the customization at runtime based on that.
The number of customizations is potentially large, and we would like to avoid prebuilding and storing these installers.
I'm open to consider all options, especially some out-of-the-box ideas.
I think it is impossible to change a signed installer (exe/dmg) without breaking the signature.
Some ideas I'm toying with (and their trade-offs):
Store the ID in the installer download filename (Con: Brittle, browsers might change the name or append a suffix to avoid duplicate names)
Ask the user to enter a code shown on the download page (Con: some inconvenience for the user)
Provide a zip with installer and config-file next to it (Con: some users will not manage to unzip, or only unzip the installer without the config file)
On Linux the installer shell script can be modified at download time, as the script cannot be signed.
Set up a server that builds and signs installers on the fly at the time of the download request. To speed this up, it could be yet another installer wrapping the main installer, and it's only task would be to extract and run the main installer with the ID parameter. (Con: complex infrastructure, code signing certificates on the public facing server, very slow for MacOS notarization)
Chromium-based browsers like Google Chrome, Chromium, Opera, Microsoft Edge, etc. save the URL of origin and the referrer URL for all downloaded files on Windows 10 (only on NTFS file systems) and Linux (only on Ext4).
For details see for example here. On Windows the metadata is also accessible from command line or direcly from Java.
There seems to be a similar feature on Mac. See for example this question on superuser.
Accessing this metadata from within your installer could help to customize the behavior of your installer. While the data will not be available in all setups (e.g. Internet Explorer stores only a zone ID and no URL) and may get lost (e.g. a user deletes the data or copies the file to a file system that does not support metadata) it could propably cover the majority of your users. Asking users to enter a code when the metadata is not found could still be used as a fallback.
Main concern I would have with this approach is that the Chromium developers may decide to remove this feature in near future or make it optional, like the developers of wget (see for example here)
On latest Windows 10 I still get the following metadata for a downloaded file with both, latest Google Chrome and Microsoft Edge Browser:
[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://httpd.apache.org/
HostUrl=https://mirror.klaus-uwe.me/apache//httpd/httpd-2.4.46.tar.bz2
We have a web app that uses Java applet to manipulate files on local disk. We develop it for quite a while and we already know all types with issues an applet may have with modern OS'es and browsers and latest Java versions and new security restrictions.
Yesterday Apple rolled out its new Mac OS 10.9 Mavericks with new Safari browser (7.0). I tested our web app under Safari 7 / Mac OS X 10.9 just to find that Safari 7 (probably?) blocks access to local files from Java applet.
Although the applet (signed with valid Thawte certificate, and with all security requirements specific to Java 7u45 fulfilled) runs in unrestricted mode with full access to local file system (Java security prompt says that), on attempt to access the local file it catches fileNotFoundException:
java.io.FileNotFoundException: /Users/yury/Pictures/Paris 2012/L1050258.jpg (Operation not permitted)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:146)
at com.trackntag.a.v.a(Unknown Source)
Also when opening Java file open dialog from the applet, it displays no files and the folders in the folder selector do not have any icons (normally they should have them). When you traverse back to the root folder, you can see top level folders (bin, cores, dev, home, and so on), but you cannot browse into them.
The applet does have an access to local files with latest Firefox 24 for Mac, on the same machine (Java 7u45, Mac OS X 10.9). Same with Safari 6 and Mac OS X 10.8.5, not to mention Linux and Windows machines in various configurations: no issues with accessing local files.
Having all of above, I must conclude that we have ran into the problem specific to Safari 7.
Do you have any ideas on this issue? Any thoughts are greatly appreciated.
Cheers,
Yury
EDIT (Answer): In Safari 7 there is a new security setting: Safe/Unsafe mode (I think it's for Java plug-in only). You can allow Java plugin to work in Unsafe mode either for individual websites or for all sites. In Unsafe mode the applets will have unrestricted access to local file system.
It appears that this security setting works on top of Java's own security settings (restricted/unrestricted access).
This setting is available through Safari preferences / Security tab / Internet plugins: manage website settings (then select Java plugin).
So once I already answered my own original question, I would rather rephrase it: is that possible to set Unsafe mode or override Safe mode for specific web-site / URL without asking user to set this security preference? Maybe something like Apple developer certificate would help?
Thanks again!
I had a similar problem with another Java app today. I think you may need to add your app to the "Allow the apps below ..." list in this dialog (System Prefs -> Security & Privacy -> Accessibility):
For Safari 11:
go to Safari Preferences->Websites->Plug-ins, and select Java
at the right side you can see list of 'Allow websites to use this plug-in with
settings below'
now select the website
press and hold Option button and then click the three option (Ask, Off, On), you will see additional option 'Run in safe mode' - un-check this option.
I have a Java Web Start application, which I've tested on Windows 7, Linux and Mac OS X 10.7 (works fine on all).
On Mac OS X 10.8 Mountain Lion the following error occurs, with no option to choose "Allow".
The error looks like this:
Does anyone know of a workaround for this?
Just found a solution: Go into System prefs -> security and privacy, and check the box that allows applications to be downloaded from anywhere (you might have to click the lock to make changes to this)
This is because of a new feature in Mountain Lion known as 'Gatekeeper'. Following is a brief description:
Choose where apps are installed from:
Gatekeeper gives you three security options for downloading and installing apps for your Mac. You can download and install apps from anywhere, with the same protection that OS X Lion provides. For maximum security, choose to allow only apps from the Mac App Store to be installed. Or download and install apps from the Mac App Store and apps that have been signed with a Developer ID.
Gatekeeper alert:
Mountain Lion alerts you if you download and try to install an application from a developer who does not have a Developer ID.
Manual override:
If you receive an alert that an app is from an unidentified developer, you can still choose to install it. Control-click the installer or the application icon to reveal a contextual menu. Choose Open and you’ll see a dialog that allows you to install the application.
I had this same problem. I would also add that once the app is installed and you know it's working. You can revert the setting that you changed to set your mind at ease in terms of your OS X Security.
Regards
Click "Show details"
Tick the "Always trust "…"" which refers to the expired (or whatever) certificate involved
Click continue, and authorise the change in cert trust settings, "Update settings", which is added to your keychain
if "Allow" is still greyed out, relaunch
I recommend going to command line and using the following
$ sudo installer -pkg /path/to/installer -target /
and viewing the output. If you receive an error about the installer being untrusted and you know the source is accurate and you want to install it anyway, then
$ sudo installer -pkg /path/to/installer -allowUntrusted -target /
This is an issue with MacOS 10.8 and older installers using a different code signing tool than what Mountain Lion likes. Or so I'm told.
This has nothing to do with Gatekeeper. I have Java 7 (JRE build 1.7_09) and I do have this popup. I also allowed everything in Security. The site I use is for banking but please note mydlink does not work, either, nor does the Yahoo finance screen.
This is the same exact thing that I had experienced back in 2003 on my Jaguar back when the Java RE was completely outside. Now, Apple handed it back to Oracle and look what happened (not to mention the font resolution on the Java window.
it is not accessing the certificates (or lacking the signatures). Solution would be simple if anybody at Oracle could program for this platform. Appe had fixed it and now they pulled the rug from under us. Java is not the future but tell it to my bank...
OK here is he fix , just set your clock to manual and take it back a couple of years, then install the program and set your date and clock back to auto
sorted
I am deploying a signed & trusted applet. We need to run the applet in a separate JVM & increase the heap size. Setting separate_jvm & java_arguments works on our local boxes. Curiously we have clients that though they are using 1.6.0_15 don't seem to be running the new plugin architecture.
When I check their Java config, "use next-generation plugin" is checked & IE7's option "use Java 1.6.0_15 for applet plugin" is also checked. Nothing seems obviously wrong. The Java console also reports the correct version, but neither separate_jvm nor java_arguments are respected.
Just as a sanity check we wrapped the applet in a JNLP & set up our web page to serve the applet with a jnlp_href. The applet tag had a bogus code parameter to ensure the JVM was actually running the JNLP. The Java console complains that it cannot find the bogus class when it should be properly loading the JNLP.
Are there security settings or something else that might cause what I'm seeing?
I'm afraid I've just a few suggestions rather than an absolute answer.
The Java virtual machine version
and plug in version can be
different. Go to Control Panel,
Java, Runtime Environment settings.
When you check the console it may
show the two different versions.
The new plugin architecture would
depend on browser, Opera doesn't use
it at all, for example. IE7 does
though. So check which browser it
works on.
Java has got corrupted due to
repeated installs and uninstalls.
Pretty common complaint I've found.
If you have control over one of the
machines you should uninstall every
Java. Restart machine. Install
latest Java.
We have a multi-platform Java-based system that spawns Robohelp for its online user guide information. It runs on a variety of Windows and Linux flavors. The default Robohelp code that is relevant to our Linux-based systems has a hard-coded link to "netscape" in the command line that it builds to spawn a web browser to view the help files. This is, obviously, less than helpful on a system that does not have netscape installed.
What I would really prefer to do is to detect the Preferred Applications preferences from Java when running on Linux. On the Fedora 9 machine where I'm currently sitting, this is found under System -> Preferences -> Personal -> Preferred Applications. The very first setting is "Web Browser."
How would I detect that setting from Java code?
Have a look at java.awt.Desktop. That supports opening/editing/printing a file in the user's preferred program, opening a URL in the user's preferred browser, sending a eMail, ...