Activity Log : GSoC Week #08 (9.VI - 15.VI)

I'll be shorter this time, summarizing in a few lines the activity for last week's final half and the issues appeared at the beginning of this one:

• removed quite a few bugs from CallSessionImpl and TransformManager
• passed the problem with the NoClassDef exception through some refactoring adding Werner's ZRTP4J sources inside the SC tree
• refactored the refactoring to bring back ZRTP4J in the initial structure and solved the NoClassDef exception the right way by adding the ZRTP4J sources inside the media.jar at build time through build.xml; this approach will permit the future modification to integrating ZRTP4J through a jar very easy - the imports will remain in the same form as now, and the lines in the build.xml will be changed to reflect the jar integration, similar to how the bouncycastle jar is handled at the moment
• modified the used ZRTP4J sources with Werner's last sources version
• got stuck into a problem, since this week started, related to how JCE (Java Cryptography Extension) works - detailed below
• added the current sources on the java.net sip-communicator dedicated branch - https://sip-communicator.dev.java.net/svn/sip-communicator/branches/encryption

Now, a few more words about the problem I'm facing. Probably the best way to start explain it is actually pasting the exception I get:

[java] java.lang.SecurityException: JCE cannot authenticate the provider BC
[java] at javax.crypto.SunJCE_b.a(DashoA13*..)
[java] at javax.crypto.Mac.getInstance(DashoA13*..)
[java] at gnu.java.zrtp.ZRtp.(ZRtp.java:325)
[java] at net.java.sip.communicator.impl.media.transform.zrtp.ZRTPTransformEngine.initialize(ZRTPTransformEngine.java:641)
[java] at net.java.sip.communicator.impl.media.CallSessionImpl.initializeRtpManager(CallSessionImpl.java:1578)
[java] at net.java.sip.communicator.impl.media.CallSessionImpl.allocateMediaPorts(CallSessionImpl.java:1519)
[java] at net.java.sip.communicator.impl.media.CallSessionImpl.createSessionDescription(CallSessionImpl.java:989)
[java] at net.java.sip.communicator.impl.media.CallSessionImpl.createSdpOffer(CallSessionImpl.java:573)
[java] at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.createOutgoingCall(OperationSetBasicTelephonySipImpl.java:257)
[java] at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.createCall(OperationSetBasicTelephonySipImpl.java:116)
[java] at net.java.sip.communicator.impl.gui.main.call.CallManager$CreateCallThread.run(CallManager.java:833)
[java] Caused by: java.util.jar.JarException: Cannot parse reference:file:sc-bundles/media.jar
[java] at javax.crypto.SunJCE_c.a(DashoA13*..)
[java] at javax.crypto.SunJCE_b.b(DashoA13*..)
[java] at javax.crypto.SunJCE_b.a(DashoA13*..)
[java] ... 11 more

Ok, the main points of interest, to say so, are the two bolded lines. After some "Google research" done, I've reached a conclusion for the moment (but I'm not very sure about it..). The SecurityException is thrown because the Sun provided implementation of the JCE needs to authenticate any Provider used for cryptography services. According to the bouncycastle site their jar is signed, but... the jar I use at the moment isn't actually the original jar from their site. It is a modified version, made by Su Bing last year, for which I don't know exactly the modifications made. Still, I don't know if the problem resides at the used bouncycastle jar because the exception states it is caused by a jar exception of not being able to parse the media jar. Why is the media jar involved in all these ? Because the contents of the bouncycastle jar were integrated by Su Bing last year at build time through build.xml in the media.jar, which represents the media bundle, in order to be possible to use bouncycastle services. This is related to the OSGi bundle architecture, and was, as far as I can tell after some testing done about a month ago, the reason for the modifications done by Su Bing to the bouncycastle jar = using the original one as it is results in the media bundle failing to start (if I recall corectly). But, as I said before, I'm not sure if the SecurityException thrown is related to these modifications (which again I don't know exactly what about they consist in or how significant they are) or if it is based only on the fact the the bouncycastle code is "embedded" inside the media jar.

Ok, this is the description of the problem. Since Monday I was able to think on some solutions, but I'm not sure any of them will work (or how good they are).

One - quite innapropriate - found after another round of "Google research" can be to use a clean-room JCE implementation which won't try to check at runtime if the bouncycastle provider is authenticated. Like I said I find this quite innapropriate regarding the fact that the bouncycastle jar is signed and in theory there shouldn't be a problem related to the authentication. Besides that, I've looked a bit for some clean room JCE implementations and there aren't many of them (though I didn't do exactly an extensive search - BouncyCastle provides one and I found one more provided by Cryptix). Add to this that I don't know if they're compatible with the current sources (the BouncyCastle one is JDK 1.3 compliant and about the Cryptix one I'm not very sure). Anyway, this approach might be a temporarily solution if nothing else works.

The other solutions focus on eliminating the cause of the problem, rather than effect, about which cause I'm not sure what actually is it, as stated above, in the problem description. So, one option, would be to try separate the bouncycastle jar from the media jar and to import it as an external source, which I don't know if it's possible. If I recall correctly there is a Bundle-Classpath parameter available for the OSGi bundle manifest, but at this very moment when I'm writing I'm not sure if it could be of some use for this. I'll do a bit of research to find out, but any feedback from someone experienced with the OSGi architecture for this and actually for a possible solution for the whole matter should be very helpful.

Another solution, which again I don't know it will solve the problem is to try using the original bouncycastle jar. For this I should try using it again, compare the logs and the behavior, and see if I can't figure out what is the problem exactly. If this won't be enough (and according to last time attempt, might not be..) I'll probably should unpack the modified one and look at the differences (there is a small problem here - the modified one is version 1.37 and the bouncycastle provided one reached version 1.39 meanwhile, and I don't see any web archive with older releases on their site, but maybe I didn't look deep enough.. and anyway a comparison should be possible between different versions too).

This is pretty much what I have in mind at this moment as possible solution. Any feedback about any part of the problem - cause or solution is very welcome.

In the next part of this week, I'll try to find a way to solve it and do some more debugging for the current sources in parallel if possible + adding the SAS support as a provisional solution in the main GUI interface until integrating it through a plugin.