Tuesday, August 23, 2016

Signing NetBeans modules with a Time Stamping Authority (TSA)

Signing JAR files is a very good practice. And while a proper certificate is not worth the price and effort, self-signing is still a step in the right direction.

Ever since Java 5 jarsigner supported a Time Stamping Authority (TSA) with the --tsa and --tsacert parameters. A Time Stamping Authority is basically an online digital notary that certifies the point in time the jar was signed -- it is designed to prevent signing files after the certificate expired.

It turns out that while you can sign NetBeans modules using the FAQ steps, there is no support in the build harness for a TSA.

I found bug #243213 which also mentions NBM problems and I submitted a patch there.

So, if you want to also add a timestamp to your NBMs, apply this small patch on top of your NetBeans source repository and rebuild NetBeans.

Then, you just have to define in nbproject/project.properties another key with your TSA (I'm using StartSSL's here):

tsaurl=http://tsa.startssl.com/rfc3161


Wednesday, August 03, 2016

Forcing export of internal API in Java 9 with -XaddExports

I've long been a fan of NetBeans' module system and of OSGi so Java 9's modules are a big improvement to me.

Except modules are really good at enforcing API boundaries and stop allowing one to freely use any public class.

An error such as this is no fun:

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.IllegalAccessError: superclass access check failed: class A$1 (in unnamed module @0x3fb6a447) cannot access class jdk.nashorn.internal.ir.visitor.NodeVisitor (in module jdk.scripting.nashorn) because module jdk.scripting.nashorn does not export jdk.nashorn.internal.ir.visitor to unnamed module @0x3fb6a447

I've assumed that this has to be tweaked at SecurityManager level and played with -Djava.security.manager and -Djava.security.policy and the very handy -Djava.security.debug.

Alas, that doesn't help. (Although I'm still convinced it should, unless there is a bug somewhere).

What one needs to use is the magical -XaddExports flag. This forces an export and allows the code to run:

java -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.ir=ALL-UNNAMED -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.parser=ALL-UNNAMED -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.runtime.options=ALL-UNNAMED -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.runtime=ALL-UNNAMED -XaddExports:jdk.scripting.nashorn/jdk.nashorn.internal.ir.visitor=ALL-UNNAMED A


The case of the different jsch 0.1.54 binaries

As part of the Apache NetBeans IP clearance we are combing through all the code and dependencies. One interesting thing we bumped into wa...