ROS KO’s 64-bit Linux

Posted in Rants, Linux by AST on Thursday, May 15th, 2008

Amoxil Generic Buy Clarinex Online Neurontin Without Prescription Topamax No Prescription Soma For Sale Glucotrol Generic Buy Aricept Online Stromectol Without Prescription Lotrisone No Prescription Celexa For Sale

I’ve been meaning to write this post for a few weeks now, but I’ve just been too busy. Now that I’m finally starting to get a bit more caught up (and after I thought about it again today when using Windows XP on VMWare to access ROS) I figured I’d better write it.

Previously, I’d figured out a way to convince ROS to work under Linux. What I didn’t realize at the time was that it only works on 32-bit Linux and not 64-bit. There are probably a couple of reasons for this sorry state of affairs. First, Sun isn’t going to provide a 64-bit Java plug-in until the release of Java 7 (or 1.7 if you’re one of us old-timers that’s worked with it since the beginning). Second, I’d say that the core “kcrypto” part of the way ROS works hasn’t been revisited in a while (since it’s built on Baltimore’s crypto stuff, and they haven’t been in this space for about 5 years).

Therefore, if you must have access to the Irish Revenue’s ROS business services from Linux, you’d better stick with either a 32-bit OS, or at least the 32-bit version of Firefox. I’ve tried every 64-bit Java plug-in that I can get my hands on, but to no avail. I’m harboring secret hopes that maybe when Sun releases Java 7, it’ll break ROS and they’ll have to revisit it in a way that makes it more accessible to non-Windows hosts, but I don’t think I’ll be holding my breath.

The closest I’ve gotten is with the gcj/icedtea version, but I get the following error:

jvmcheckerurl /java/javachecker.jsp
readBrowserDetails:: JVM Vendor: Sun Microsystems Inc., JVM Version: 1.6.0Kcrypto Installed? trueKCrypto Version: 8,0,1,0
Crypto release KeyTools Crypto v5.2
Crypto version 5.2
KCrypto present
getBrowserDetails:: JVM Vendor: Sun Microsystems Inc., JVM Version: 1.6.0Kcrypto Installed? trueKCrypto Version: null
getJVMVendor().trim().equals(browserDetail.getJVMVendor().trim()) true
getJVMVersion().trim().equals(browserDetail.getJVMVersion().trim() true
this.isKcryptoInstalled()==browserDetail.isKcryptoInstalled() true
 readBrowserDetails().equals(getBrowserDetails()) true
readBrowserDetails:: JVM Vendor: Sun Microsystems Inc., JVM Version: 1.6.0Kcrypto Installed? trueKCrypto Version: 8,0,1,0
Crypto release KeyTools Crypto v5.2
Crypto version 5.2
KCrypto present
getBrowserDetails:: JVM Vendor: Sun Microsystems Inc., JVM Version: 1.6.0Kcrypto Installed? trueKCrypto Version: null
getJVMVendor().trim().equals(browserDetail.getJVMVendor().trim()) true
getJVMVersion().trim().equals(browserDetail.getJVMVersion().trim() true
this.isKcryptoInstalled()==browserDetail.isKcryptoInstalled() true
matchBrowserDetails==true
GCJ PLUGIN: thread 0x622920: plugin_in_pipe_callback
GCJ PLUGIN: thread 0x622920: plugin_in_pipe_callback: setting status exception: java.security.AccessControlException: access denied (java.security.SecurityPermission putProviderProperty.JCRYPTO).
  PIPE: plugin read: status exception: java.security.AccessControlException: access denied (java.security.SecurityPermission putProviderProperty.JCRYPTO).
GCJ PLUGIN: thread 0x622920: plugin_in_pipe_callback return
  PIPE: appletviewer wrote: status exception: java.security.AccessControlException: access denied (java.security.SecurityPermission putProviderProperty.JCRYPTO).
java.security.AccessControlException: access denied (java.security.SecurityPermission putProviderProperty.JCRYPTO)
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:342)
	at java.security.AccessController.checkPermission(AccessController.java:553)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at java.lang.SecurityManager.checkSecurityAccess(SecurityManager.java:1715)
	at java.security.Provider.check(Provider.java:403)
	at java.security.Provider.put(Provider.java:326)
	at com.baltimore.jcrypto.provider.JCRYPTO.<init>([DashoPro-V1.3-013000])
	at com.baltimore.psd.revenue.applet.AuthenticateApplet.init(Unknown Source)
	at sun.applet.AppletPanel.run(AppletPanel.java:436)
	at java.lang.Thread.run(Thread.java:636)

Doing a bit of digging on Google is actually kinda difficult, but eventually just searching for the putProviderProperty.JCRYPTO part yields the following gem (on the Java Forums from 1998!):

If you take the cert that either KeyTools or BouncyCastle is signed with and look at the netscape cert type extension you can see that it has the following fields set:

SSL Client Authentication,SSL CA,SMIME CA,Signature CA (87)

You will note that ObjectSigning is not there which is really odd for a “codesigning” certificate.

A bit of a google search brings up this link (I can’t find this doc on sun’s site)

http://www.archive.cc.yamaguchi-u.ac.jp/apl/jce1.2.1/BUGS.html

The JCE Code Signing CA uses Netscape CMS 4.1 to import Certificate Signing Requests (CSRs) from users and generate code-signing certificates that the users can utilize to sign their providers or exempt applications. The CSRs generated by keytool are in the PKCS#10 format. A bug in Netscape CMS 4.1 causes it to be unable to import a PKCS#10 request if it is directed to generate an object (code) signing certificate. But it can import a PKCS#10 request if it is directed to generate an SSL server certificate. This problem is expected to be fixed in Netscape CMS 4.2.

Workaround: The JCE Code Signing CA will issue SSL server certificates for code signing for now. It will be able to issue object signing certificates once we upgrade to Netscape CMS 4.2 after it becomes generally available

I presume that both we (baltimore) and BouncyCastle would need to get our codesigning certificates re-issued by Netscape CMS 4.2 before they would be accepted as individually signed jars by the java plugin.

Note:I emailed the java-security list about this almost 2 weeks ago with no response to date.

regards

kevin

Kevin O’Regan
Team Lead
KeyTools Pro Java, Baltimore Technologies.

Not wanting to take the time to figure out how to turn on the security debugging for the plugin (mentioned by Kevin earlier in his reply), I don’t know if this is the same issue or not, but my guess is that someone’s decided that Java 7 should actually get rid of some of the workarounds included over the years (at least for the pre-releases). This choice could very well cause really old code (presumably like ROS’s kcrypto.jar) to break in new (or old) and exciting ways.

Even if I did take it further and figured out what was actually wrong, I’m not sure I could fix it this time. In the amount of time I’ve spent arsing around with trying to get it working, I could’ve bought VMWare Workstation (twice!), so it isn’t really a very good use of my time.

It is a shame to see how poor 64-bit client operating system support is at the moment. Even Vista doesn’t come pre-installed on new machines in 64-bit mode. If I wanted a 32-bit machine, I’d have kept my old ones. I don’t understand the mentality of why vendors think this is a good thing because 32-bit code works in backwards-compatible mode. That’s like buying a V8 and then unhooking the fuel injectors to half the cylinders. It just doesn’t make any sense.

Maybe after 64-bit x86 processors have been out for 5-6 years—oh wait…

2 Comments »

  1. John Moylan said,

    November 9, 2008 at 3:00 pm

    Have you gotten it working with 32bit Firefox on 64bit Linux with 32bit Java?

  2. AST said,

    November 9, 2008 at 3:15 pm

    Hi John,

    Glad I could help you get things working. To be honest, I gave up. I actually do have to have a VMWare instance of Windows XP for dealing with some of our clients, so I just ended up using that every month instead.

    I’d much rather do it all from Linux, but I’m not going to start installing 32bit apps just for Revenue. I keep hoping that they’ll either have to update it, or that the new JVM for 64-bit linux will magically make things work.

    Other fish to fry at the moment… ;)

Leave a Comment