Skip to main content

sign-xlets is Failing with a Signature encoding error

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
3 replies [Last post]
onebeartoe
Offline
Joined: 2011-08-24

I had some time to re-visit HDCookbook project, but running the Ant build script at the root of the Subversion check out (https://svn.java.net/svn/hdcookbook~svn) gives an error at the sign-xlets task. Here is a snippet of the error:

[jdktools.java] java.security.SignatureException: Signature encoding error
[jdktools.java] at sun.security.rsa.RSASignature.engineVerify(RSASignature.java:208)
[jdktools.java] at java.security.Signature$Delegate.engineVerify(Signature.java:1172)
[jdktools.java] at java.security.Signature.verify(Signature.java:623)
[jdktools.java] at sun.security.pkcs.SignerInfo.verify(SignerInfo.java:392)
[jdktools.java] at sun.security.pkcs.PKCS7.verify(PKCS7.java:543)
[jdktools.java] at net.java.bd.tools.security.SecurityUtil.signWithBDJHeader(Unknown Source)
[jdktools.java] at net.java.bd.tools.security.SecurityUtil.signJarFile(Unknown Source)
[jdktools.java] at net.java.bd.tools.security.SecurityUtil.signJars(Unknown Source)
[jdktools.java] at net.java.bd.tools.security.BDSigner.main(Unknown Source)
[jdktools.java] Caused by: java.io.IOException: ObjectIdentifier mismatch: 1.3.14.3.2.26

I attached more of the Ant output as well.

Does anybody know how to resolve this?

AttachmentSize
errors.txt4.15 KB

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
billf
Offline
Joined: 2004-02-13

This is a guess, but could there be an old key repository somewhere in your directory hierarchy? I'm guessing this might be the case, because of the ObjectIdentifier mismatch IOException... that sounds like an object being deserialized. The only place I can think of that would have an old object that might be deserialized would be the key repository.

If this turns out to be the case, then it's a bug in the Java runtime platform... Serialized objects are supposed to be forward-compatible in this way, but accidents to happen.

Anyway, try an "ant spotless" followed by "ant". "ant spotless" is supposed to clean out everything, and return the workspace to a "pristine" state, like when it was first checked out. It specifically cleans out key repositories -- and prints out an error message telling you so!

If that doesn't work, try checking creating a new workspace from scratch... It's not impossible that "ant spotless" might miss something, particularly something from an older version of the repository. If a brand new workspace exhibits this error, then at least that will rule out some potential failure points!

Cheers,

Bill

onebeartoe
Offline
Joined: 2011-08-24

Hi Bill. Thanks for your quick response. I indeed did check out the HDCookbook from the repository, from scratch.

I also followed your advice to run 'ant spotless', but the same error occurs.

I am not sure if this makes a difference, but here is the output from java -version
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.6) (6b22-1.10.6-0ubuntu1)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)

Attached is the output from 'svn status' and 'svn diff'. You'll notice I haven't made any changes the signing aspects of the Ant build scripts.

The error message contains 'ObjectIdentifier mismatch: 1.3.14.3.2.26' which implies something about Bouncy Castle. I tried dropping in their latest release (bcprov-ext-jdk15on-147.jar), but there were too many API changes for it to still be compatible with the HDCookbook as is.

Do you have any other ideas on how to correct this?

Thanks,

Roberto

billf
Offline
Joined: 2004-02-13

Hmmm... It still looks to me like a bug in the Java platform's runtime, where one part of the security infrastructure is using a different version of something than another part. I could well believe that OpenJDK might get less extensive testing in this corner of the platform than the Sun runtimes. Do you have access to an environment with a Sun JDK installed?

I double-checked and did a build on OSX, which is:

billf@/Volumes/case_sensitive_tmp$ java -version
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)

Now that JDK 1.7 is available from Oracle on Mac, I might try upgrading to that, but for now I'm on the Apple-supplied Sun runtime. It auto-updated relatively recently, so I'm current in OSX-land :-)