Pivotal Web Services (PWS): All versions
You have a Java or alternative JVM language application that you want to deploy on PWS and require strong cryptography (i.e. the unlimited strength policy for JCE) in the application.
By default, we are not allowed to ship the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files with the build pack. The following article will walk you through the process of enabling it for your application.
- Login to Github and navigate to the page for the Java BuildPack.
- Click the Fork button in the upper right corner. This will make a copy of the build pack under your account that you can freely edit.
- Open a command prompt or terminal on your PC. Change to a directory where you'd like to store the build pack files and run git clone to copy the files to your local machine.
git clone https://github.com/<your-github-userid>/java-buildpack
- Download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from Oracle. Java 7 or Java 8
- Place the local_policy.jar file into the resources/open_jdk_jre/lib/security/ directory of your clone of the build pack. Commit the changes and run git push to upload them back to Github.
- The last step is to instruct PWS to use your version of the build pack instead of the default version. This can be done in two ways. You can either pass the -b argument to cf push and give it the URL to your build pack or you can set the buildpack attribute in your manfiest.yml file with the URL to your buildpack. Either way, you'll need to push the application again as the system will need to stage your application using the new build pack.
You can confirm that things are working correctly by looking at the output from your application staging. At the top you should see it list the URL from your build pack.
As of java buildpack version 3.7.1 and higher JCE unlimited strength is enabled by default. There is no longer need to overlay local_policy.jar into JRE, so long as buildpack is at upgraded version. The java buildpack version can be validated by command cf buildpacks.
The risk of using a fork of the build pack is that you will no longer receive automatic updates to the build pack. Normally the build pack author makes changes to the build pack and you'll pick these up as they become available. If you fork the build pack, you will not automatically receive these updates. Instead, you'll need to manually pull them in to your fork of the build pack. Merging change is outside the scope of support for PWS, but can be done with the instructions provided by Github here.
By default, the Java buildpack will automatically select the most recent minor version of the components that it uses. This includes selecting the latest minor version of Java and Tomcat (this happens even if you fork the buildpack). This behavior is important as it keep your application up-to-date with the latest security and bug fixes for the components. If you use the instructions above to select a fixed version of a component (i.e. you remove the trailing plus sign from the version number), you will disable this behavior. We do not recommend doing this as it could leave you vulnerable to known security problems with the software.