The v2 signature scheme for application bundles on Mac OS X 10.9.5+

Apple has decided to introduce a new signing scheme in the upcoming Mac OS X 10.9.5 maintenance release.

The good news is that the new signature is much better from a security point of view. The utility of the old signature was highly questionable, because it allowed unsigned and modifiable files in the application bundle. An attacker could change the JAR files in the application bundle and the signature of the application bundle would remain valid.

The bad news is that all existing signatures are going to break. Only applications with a v2 signature will be accepted by Gatekeeper starting with Mac OS X 10.9.5. On the upside, the v2 signature is backwards compatible with older versions of Mac OS X. The means that if your application bundle is signed with the new scheme it will work in Mac OS 10.8, 10.9 and 10.10 - and hopefully even with future versions of Mac OS X.

We have implemented v2 signatures in install4j 5.1.13, so you can already create application bundles that will work with the upcoming disruptive releases of Mac OS X.

However, this change may have consequences for your install4j projects:

  • The application bundle that is installed by a "Mac OS X single bundle" installer cannot be signed anymore. The installer installs variable files into the bundle and of course it cannot update the signature of the bundle. Previously all these files did not influence the signature (you can see that this was a bad idea), but now everything in the bundle must be signed. If you really need a signed launcher, you have to switch to the "Mac OS X single bundle" archive.
  •  Info.plist files and .vmoptions files in signed bundles cannot be changed anymore without breaking the signature. If you rely on the validity of the signature of the application bundle, you have to ensure that these files remain untouched. This applies to single bundle and folder archives as well as to the folder installer with signed launchers enabled.

To make the correct decisions, you have to understand that a signature is only required for the file that user downloads from the internet. An installer can install application bundles that are unsigned, because those will not be checked by Gatekeeper.

A signature on an installed application bundle is only required if you need access to restricted services, such as iCloud storage or the notification center. In addition, signed application bundles are treated preferentially in some cases. For example, if the user enables the firewall, unsigned application bundles can only receive incoming connections after the user confirms a question from the firewall.

Introducing perfino

Today we're releasing a major new product: perfino is a JVM monitoring tool for in-production use. Over the years, we have lost count of the number of times that our customers have asked us on how to best deploy JProfiler in production. While our standard response was to recommend a monitoring tool, our customers were not so easily dissuaded. They wanted the power of JProfiler to solve their particular problems.

Out of this dilemma, the idea for perfino was born. Would it be possible to develop a monitoring tool that could be used in production, yet provide a way to escalate from monitoring to profiling if necessary? We are firmly convinced that perfino succeeds with respect to this original goal and provides you with a layered defence in depth. When a problem becomes more difficult to solve with monitoring techniques, perfino offers low-risk, low-overhead native JVMTI sampling to get a picture of the entire JVM. If even that is not enough, perfino offers an easy way to attach JProfiler to a problematic JVM. At that point, you have the full arsenal of a Java profiler at your disposal.

However, the much larger part of perfino is not its emergency handling, but its monitoring capabilities. Here, we wanted to make a difference as well. perfino uses a Java agent with ultra-low overhead and measures what is called "business transactions" in the APM space. Business transactions capture important method calls with specially constructed names that help you to interpret what is going on in your application.

For business transactions, we brought in successful concepts from the profiling space and integrated them into perfino. For example, transactions are shown in a call tree and you can see hot spots of transactions. With perfino, it is possible to define many transactions that are nested. This gives you more informational depth and correspondingly more insight than just the list of top-level business transactions that is common for APM tools.

The amount of useful information in an APM tool is directly related to the amount and quality of the recorded business transactions. This is why we expended a lot of energy on the business transaction engine and the configuration of business transactions in the perfino UI. Also, we wanted to make it really easy to define business transactions directly in your code. The DevOps annotations offered by perfino are a great way to achieve this. Rather than thinking about monitoring as external to the application, you just annotate methods of interest.

The features mentioned above rotate around measuring method calls. Of course, a monitoring tool needs to do a lot more and we’ve strived to make perfino great in all these aspects: Telemetries, policies, triggers, alerts, end user experience monitoring and lots more. Take a look at the feature list or - even better - try it out in our live demo or on your own machines. Tell us what you think and what you would like to see in future versions.


perfino is a powerful APM solution today, but our vision for perfino is not done yet. There are many more things to come and we hope you’ll bear with us.

Java profiling across JVM boundaries

This screen casts shows "Remote request tracking" in JProfiler. It makes it possible to profile business transactions that span multiple JVMs. Here, a web service call to another JVM is shown and profiled in isolation of other requests that are handled by the server. In addition, JProfiler supports remote request tracking for RMI and remote EJB calls.

Profiling MongoDB

This screen cast shows how to use the MongoDB probe in JProfiler that has been added in JProfiler 8.0. The profiled application is the vert.x web demo application that uses mongodb as a storage option. MongoDB events are correlated to the the activity in the web application and it is shown how the exclusion of primitive data leads to a useful definition of hots spots.

Profiling class loaders and solving related memory leaks

This screen cast shows how the class loaders probe can be used to debug class loading and to solve class loader memory leaks.

All screen casts now with HTML5 video

We've just converted all our screen casts to HTML with MP4 and WebM codecs so you can enjoy them on mobile and other Flash-less devices.


There still is a Flash fallback for ancient browsers that do not support the "video" tag. Some older browsers (such as Firefox 3) that support the video-tag but do not support either the MP4 or the WebM video codec may show an error. In that case, please go to our youtube channel to watch the screen casts.

--- Update 2013-07-24

Since Firefox 21, MP4 is supported on Firefox if you're on Windows 7 or higher. There may be problems with colors that are resolved if you go to about:config and set

media.windows-media-foundation.use-dxva=false

Migrating to install4j 5.1

The following new features in the install4j 5.1 require consideration when migrating from 5.0:

New architecture for elevated privileges


install4j 5.1 introduces a new architecture for elevated privileges. Under some circumstances this can create backwards compatibility problems with your existing projects that are discussed below.

Prior to install4j 5.1, the the "Request privileges" action could restart the entire installer process and run the installer GUI and all the actions with elevated privileges. This was the default setting on Windows and also available on Mac OS X. The unelevated process was kept around only for starting launchers and other executables without privileges. On Mac OS X, the default mode for the "Request privileges" action was to start an elevated helper process that was used internally by some actions - such as the service actions. The strategy of running the GUI without elevated privileges is a lot better, but our helper process had very limited capabilities and so it could not be made the default on Windows.

Enter install4j 5.1: We have now removed the "restart" and beefed up the elevated helper process considerably. Single actions can now be executed in the elevated helper process. To this end, we have added an "Action elevation type" property to all actions in the install4j IDE. Unless the action declares a different default value, it is set to "Inherit from parent". The "Action elevation type" is also configurable on screens, installer applications, screen groups and action groups, and determines the default value for the contained actions.

If an action is set to be executed with maximum available privileges and an elevated helper process has been started by the "Request privileges" action, the action is serialized to the elevated helper process, executed there and then serialized back to the unelevated process. In the elevated helper process, it has access to all installer variables and it can interact with the GUI through the methods in the com.install4j.api.Util class. Elevated actions in console installers can use all methods in the provided com.install4j.api.screens.Console object to interact with the user.




If you are just using standard actions, migrating to install4j 5.1 should not break anything. If you use custom code, the two-process architecture and the changed default privileges might impact your installer. Here are the points that you should look at:

  • Using static state in elevated actions may have unintended consequences, since static state is not synchronized between the two processes. Only use installer variables for saving state.
  • Elevated actions must be serializable. The base interface for actions now extends java.io.Serializable, but all contained objects must be serializable as well, otherwise a fatal error will occur.
  • Installer variable values should be serializable. If you place a non-serializable value into an installer variable, you will not be able to use it in elevated actions.
  • If your action previously assumed that it would have full privileges, you have to set its "Action elevation type" to "Elevate to maximum available privileges" manually. For example, a "Run script" action that modifies a file with your own code may not work on a file in the installation directory unless you elevate the action. For custom actions, you can call setFullPrivilegesRequired or setDefaultActionElevationType in your action bean info in order to automatically set the correct elevation type in the install4j IDE when the action is inserted.
  • Some methods in the API do not work in the elevated helper process. They have been marked to throw NotSupportedInElevationException in the API javadoc. Mainly this concerns methods in the context that change the control flow (i.e. jump to another screen) or methods that modify the GUI. If your action needs to use these methods while at the same time requiring elevation, you can always use context.runElevated(...) to push a piece of code to the elevated helper process.

 The key advantages of the new architecture are:
  • Unified privileges architecture for Windows and Mac OS X
  • No more problems due to user change on authentication
  • Privileges can reasonably be requested at any point in the installer, not only at the beginning
  • Better desktop integration of the installer GUI, for example for drag and drop

Support for OpenJDK on Mac OS X 

OpenJDK is the way forward for Java applications on Mac OS X. However, the following points need your attention:

  • It is not possible to deliver an installer or a single bundle archive that support both the old Apple JRE as well as OpenJDK. The stubs are different and you choose either option in the media wizard. Old projects will keep the Apple JRE option, so nothing will change by default
  • JRE bundling on Mac OS X is only supported for Open JDK
  • The minimum Java version for OpenJDK is Java 7 and the minimum Mac OS X version is 10.7.3. So you can currently target only newer systems and only if your application supports Java 7.

Code signing for Windows and Mac OS X

Code signing on Windows and Mac OS X is now implemented in pure Java code which works on any supported platform. Previously, install4j only offered a hook for inserting an external code signing tool for Windows which would be executed for each launcher and installer application. This functionality is still available for Windows media files and is now called "Executable processing". So your existing solution for code signing will still work and there is no immediate need for action.

However, if you have .pvk and .spc files for your code signing certificate, you can enter them on the General Settings->Code Signing tab and enable Windows code signing there. You then have to remove the external code signing command on the "Executable processing" step of the media wizard.