I’m currently adding some new plumbing to hemesh using an arbitrary precision library, Apfloat. because it’s a lot slower it is only called when necessary. Including it had an unexpected side-effect. Apfloat requires information about your system when it’s running in a browser. It needs your machine’s inherent precision.

However, accessing your computer is a big no-no for my code. So unless the applets are signed, they won’t run because of security restrictions. In itself, this is not really a problem, we can still share code and show each other images. But I’d rather keep sharing applets, these always include the correct libraries and often rely on unreleased alpha-level modifications of my library.

I can’t claim a proper understanding of Java security issues and all details about signing. But I’ve been looking around and gathered masses of raw data, info-ore. I’ve smelted it down to an ingot of usefulness. In short, this is how you sign a Processing applet without knowing what you’re doing. On a Windows machine… (don’t be too disappointed, the essentials are the same on hipster machines.)

Preparations

1) First locate your Java Development Kit (JDK) distribution. If you’re using Eclipse, or program in JAVA, you probably have one around somewhere. If not, Processing has it included in its \java subdirectory. Check out the contents of the \bin folder. See all those executables, we’ll be using a few of those. Let’s say you traced your JDK to c:\processing\java. So anywhere the text mentions c:\processing\java\bin substitute this with your own location.

2) Include the \bin subdirectory in your system’s PATH. Check this if you aren’t sure how, of course use c:\processing\java\bin instead of the Matlab example. This’ll save you a lot of typing. The executables in the bin folder can now be called from any directory.

3) Create a folder to store your keystore, the repository for your certificates. I’ll be using c:\keystore.

Creating your certificate

4) Open up a command prompt (press windows+r, type cmd). If you set up the PATH properly, you can access the commands we’ll be using anywhere. Otherwise you’ll have to call them with their full path… We’ll create a keystore and a first certificate mykey now. Since our keys will be self-certified only (i.e. no certifying agency will vouch for your good intentions), we’ll give them a validity of 100 years. That should be enough…

keytool -genkey -keystore c:\keystore\mykeystore.jks -alias mykey -validity 36500

Since this is the first time the keystore is accessed, you’ll need to input some important info. Just choose a decent keystore password (let’s say passw0rd ;) ) and fill in the rest. After filling in your data, keytool will ask for the key password. You can keep this the same as the keystore password, just enter and finish. You now have a keystore with a single certificate mykey in it.

5) Now we’ll make the certificate self-certified. It’s up to the end-user whether or not he’ll trust your applet.

keytool -selfcert -keystore c:\keystore\mykeystore.jks -alias mykey

Signing your applet

6) I now have an applet I want to share and that requires signing:c:\sketchbook\condel. First export the applet. The /applet subdirectory now contains all Java archives (JAR) associated with your sketch. We’ll need to sign all of them, even if only one requires authentication.

7) Re-open the command window if necessary and navigate to c:\sketchbook\condel\applet. For every JAR run this:
jarsigner -keystore c:\keystore\mykeystore.jks -storepass passw0rd -keypass passw0rd core.jar mykey

In my case, I have core.jar, hemesh.jar, apfloat.jar and several others I’ll need to sign.

8) Done! You can upload the applet. If somebody accesses the page she will be given the choice of trusting the applet. If yes, then the applet will run. If no, then it won’t.… I’ve created condel this way.