Before I close this issue and forget about it, an interesting thing is that a plain old simple java test class, based on copy/paste of ERXBlowfish+related logic (see attached), shows that the default sun.boot.class.path for command line launch on OS X 10.6.7 does not include these **/Home/lib/ext/*.jar's.

To test this on your machine, here are the commands (for those of us who are spoiled by IDE's)

Attachment: BlowFishCrypterTest.java
Description: Binary data


Drop the java file in a new folder somewhere, navigate to the dir in Terminal and do this:

$ javac -d . BlowFishCrypterTest.java
$ java test/BlowFishCrypterTest

The output will be sth like this:

<snip>
java.class.path:
.

sun.boot.class.path:
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsfd.jar
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar
/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/Resources/Java/JavaRuntimeSupport.jar
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/laf.jar
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/sunrsasign.jar
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar

_blowfishKey = javax.crypto.spec.SecretKeySpec@d97ad666
_encryptCipher = javax.crypto.Cipher@53ad085; Provider = SunJCE version 1.6
_decryptCipher = javax.crypto.Cipher@5f7a8a02; Provider = SunJCE version 1.6
It works.
</snip>

So, maybe the fact that Eclipse grabs those references in the Home/lib/ext and ads them to the JRE Definition automatically when you try to Edit the JRE Definition is a bug?

This Eclipse JRE Definition is perhaps yet another thing to add to the Chuck Hill "Develop as you intend to deploy" mantra (http://bit.ly/fDAV2g).

Regards, Kieran


On Apr 26, 2011, at 11:45 PM, Kieran Kelleher wrote:

This is a booby-trap waiting to happen to you all who might be using ERXBlowfishCrypter (or possibly other java security features) ;-) Documenting this here so that "Future Me" will not waste time solving this problem again.

The problem was that the JRE Definition has changed kind-of-by-itself, when I opened the JRE Definition in Eclipse to add java src location at the end of last week.

Steps to reproduce in OS X 10.6.7:
1) If you haven't already done so, update to the very latest Java 1.6 Update 4 for OS X 10.6 on your OS X development Mac and restart.

2) Add this code to the end of your app initialization (in your override of ERXApplication.didFinishLaunching() for example)
<snip>
            classpath = ERXProperties.stringForKey("sun.boot.class.path");
            
            if (classpath != null) {
             classpath = classpath.replace(':', '\n');
}
            
            System.out.println("sun.boot.class.path = \n" + classpath);
</snip>

3) Run your app and check the output of that debug code in your console. If you have NOT edited your JRE definition in Eclipse Prefs in a long time, you will probably see something like this:

sun.boot.class.path = 
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/classes.jar
/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/Resources/Java/JavaRuntimeSupport.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/ui.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/jsse.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/jce.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/charsets.jar

4) Now open Eclipse Preferences => Java => Installed JREs. Select your default JVM and click Edit. Scroll to the bottom of the JRE Definition list and note the presence of a bunch of automatically added **/Home/lib/ext/*.jar's. Click Finish.

<Edit JRE.jpeg>

5) Now RESTART ECLIPSE, and run your app again and check the debug output for sun.boot.class.path. Note that it will have changed even though you did not actually Add or Remove any jars in the edit dialog. Apparently, each time you open the JRE Definition, it will automatically grab extra security provider jars inside Java Home/lib/ext, which were probably added by some Java update in between the time I installed Eclipse and now.

For more fun try and get ERXBlowfishCrypter to work while these other jars (which include security providers) are in boot path. I have confirmed that it will fail

Of interest is that some of the providers in this set of new jars are high priority security providers in the Properties file at:
/System/Library/Frameworks/JavaVM.framework/Home/lib/security/java.security

_________________________________________________

Steps to Workaround:
1) Open the JRE Definition

2) Remove all the **/Home/lib/ext/*.jar's. Click Finish.

------------------------------------------------------------------------------

In hindsight, I blame John Huss for this mess!  ;-) 

The reason I say that is because I followed his tip about adding the java javadoc at the end of last week (See John's email to the list on Friday Apr 22, 2011 10:35am), and by my mere opening of the JRE definition to add the javadoc location, these extra security jars got automatically and unknowingly added to the bottom of the list in the JRE Definition! ... which caused me to experience a broken Wonder ERXBlowfishCrypter this morning!


Regards, Kieran


PS. The problem seems to be intermittent. If you add those jars back to the JRE Definition, it may or may not cause BlowfishCrypter to fail. All I can say is that something "fishy" is going on here with the most recent java updates on OS X.


On Apr 26, 2011, at 5:22 PM, Kieran Kelleher wrote:

Ok, further investigationreveals the value of sun.boot.class.path is different between my MacPro, where I can't get a blowfish crypter, and my laptop, where everything works.

The value of sun.boot.class.path is different on both machines!! Note the ADDITIONAL sunpkcs11.jar, apple_provider.jar and sunjce_provider.jar in non-working MacPro!

Anyone know WHERE this is defined in OS X so I can verofy this as the problem with Wonder blowfish crypter??!

 ...... (btw, I tried -Xbootclasspath as a launch arg without success)

MacPro (Blowfish/ECB/NoPadding Crypter not available)
-----------------------------------------------------
sun boot classpath = 
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/classes.jar
/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/Resources/Java/JavaRuntimeSupport.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/ui.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/jsse.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/jce.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/charsets.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/apple_provider.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/dnsns.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/localedata.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/sunjce_provider.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext/sunpkcs11.jar

MBP Laptop (Blowfish/ECB/NoPadding IS available)
------------------------------------------------------
sun boot classpath = 
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/classes.jar
/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/Resources/Java/JavaRuntimeSupport.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/ui.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/jsse.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/jce.jar
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/charsets.jar


On Apr 26, 2011, at 1:34 PM, Kieran Kelleher wrote:

I restarted my MacPro last night and today, I began getting this error in one of my apps on MacPro dev machine:

java.security.NoSuchAlgorithmException: Cannot find any provider supporting Blowfish/ECB/NoPadding
  at javax.crypto.Cipher.getInstance(DashoA13*..:Unknown)
  at er.extensions.crypting.ERXAbstractBlowfishCrypter.createBlowfishCipher(ERXAbstractBlowfishCrypter.java:76)
  at er.extensions.crypting.ERXAbstractBlowfishCrypter.decryptCipher(ERXAbstractBlowfishCrypter.java:109)
  at er.extensions.crypting.ERXAbstractBlowfishCrypter.decrypt(ERXAbstractBlowfishCrypter.java:147)
  at wk.eofextensions.EncodedString.blowfishDecode(EncodedString.java:206)
  at wk.eofextensions.EncodedString.createInstanceFromEncodedString(EncodedString.java:57)
(stack trace truncated ......)

It is failing on this line in Wonder:
Cipher cipher = Cipher.getInstance("Blowfish/ECB/NoPadding");

The last update I did w Apr 17 (see attached screenshot of InstallHistory.plist). My laptop is identical OS X 10.6.7, Java update 4, Wonder version with exception of these updates. Yet, I know this code worked last week after those updates, so what gives?

Any ideas/suggestions?

Kieran

PS. And yeah, I did rebuild entire workspace, quit and restart the machine already .... more than once :-(

<InstallHistory.plist.jpeg>



 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to