OSGi Bundle of BouncyCastle / Alternate JCE Provider

BouncyCastle comes in the form of signed jar, and there is a good reason for doing so. Java JCE Reference Guide states very clearly that providers need to be signed by a trusted entity to be plugged into the JCE framework.

So, if you try to OSGi bundle BouncyCastle the resulting jar won't be signed anymore, and JCE won't be able to authenticate the BouncyCastle provider.

This is the reason we see problems like this: ZRTP integration (possible) OSGi bundle related problem and this: bouncy castle exception with osgi. Two workarounds would be to...

1. OSGi bundle BouncyCastle, but loose it's ability to be an alternate JCE provider
   
2. Add it in the org.osgi.framework.system.packages.extra list in the felix.client.run.properties and make sure it's in the class path as it is mentioned here.

If you finally choose to OSGi bundle BouncyCastle, make sure that no manifest merging occurs, or else OSGi won't be able to start your bundle, it will probably fail with something like this:

java.lang.NullPointerException
at java.util.jar.Manifest$FastInputStream.fill(Unknown Source)
at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
at java.util.jar.Attributes.read(Unknown Source)
at java.util.jar.Manifest.read(Unknown Source)
at java.util.jar.Manifest.(Unknown Source)
at org.apache.felix.framework.searchpolicy.ContentLoaderImpl.calculateContentPath(ContentLoaderImpl.java:344)
at org.apache.felix.framework.searchpolicy.ContentLoaderImpl.initializeContentPath(ContentLoaderImpl.java:315)
at org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClassPath(ContentLoaderImpl.java:90)
at org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
at org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
at org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
at org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
at org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
at org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
at org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
at org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
at org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
at org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
at org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
at java.lang.Thread.run(Unknown Source)
java.lang.NullPointerException
at org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
at org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
at org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
at org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
at org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
at org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
at org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
at org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
at org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
at org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
at org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
at java.lang.Thread.run(Unknown Source)

Subversion, SourceGear's Diffmerge and Cygwin

A while back in my Arsenal Selection post I described a way to use SourceGear's Diffmerge with Mercurial. No that I started to commit stuff to my SIP Communicator branch, I needed to do the same with SVN (which I run under Cygwin).

It turns out to be a little trickier with SVN firstly because SVN is not that versatile as Mercurial and second because I use SVN under Cygwin which results in paths being delivered in diffmerge Cygwinized.

To enable a 3d party diff tool you need add something like this in your ~/.subversion/config file (c:\cygwin\home\your_user\.subversion\config):

diff-cmd = diffwrapper.sh

With the help of Eric's post Living with Subversion and Pete's post Subversion, KDiff3, and Cygwin I've built diffwrapper.sh to look like this:

#!/bin/sh

LEFT=`cygpath -d ${6}`
RIGHT=`cygpath -d ${7}`

# thanks to jtr for the sed regex
LEFT_NAME=`echo ${3} | sed 's/.*\/\([^/]*\)/\1/'`
RIGHT_NAME=`echo ${5} | sed 's/.*\/\([^/]*\)/\1/'` #src/net/java/sip/communicator/impl/protocol/jabber/OperationSetInstantMessageTransformJabberImpl.java (revision 0)

/cygdrive/c/Program\ Files/SourceGear/Vault\ Client/sgdm.exe /title1:"$LEFT_NAME" "$LEFT" /title2:"$RIGHT_NAME" "$RIGHT"

Now you need to make sure that diffwrapper.sh script is somewhere in your PATH. I've added in ~/bin, and did

echo export PATH="\$PATH:$HOME/bin" >> ~/.bashrc

Update: Friday, 24 July, 2009
Here's a mergewrapper.sh script

#!/bin/sh
local=`cygpath -d ${3}`
remote=`cygpath -d ${2}`
base=`cygpath -d ${1}`
merged=`cygpath -d ${4}`
/cygdrive/c/Program\ Files/SourceGear/Vault\ Client/sgdm.exe /result:"$merged" /title1:"Local" /title2:"Merged" /title3:"Remote" "$local" "$merged" "$remote"

Publishing your java.net SVN commits using Yahoo! Pipes

hapdaniel has a nice post about HTTPS, Pipes and YQL. Based on that post, here's a pipe that builds an RSS feed that shows your personal SVN commits to SIP Communicator.

Working with your SVN branch - Merge trunk changes to your branch

Now that the java otr library otr4j is functional, I wanted to merge any trunk changes back to my SIP Communicator branch, prior tto getting to work with SIP Communicator. I decided to post this because I always find my self googling for the answer..

this actually involves 4 commands:

1. svn update, you run svn update to sync your working copy so svn info will show you updated information.
2. svn info, running svn info will reveal the current HEAD revision (r2) as well as the revision of the last change of your branch (r1).
3. svn merge, having these two pieces of information you can run svn merge -r r1:r2 trunk_location
4. svn ci -m "Merged trunk changes r1:r2 into my branch"

Update: Friday, July 24, 2009

If you have time I would recommend reading at least Subversion in Action and Branching and Merging from the book Version Control with Subversion.

The procedure described above is not correct. It is simpler in >= 1.5 setups and, occasionally, more complicated in < 1.5 setups.

MiniMax and stsp on #svn channel on Freenode kindly answered my questions regarding some issues I had. I have to incorporate the outcome of the discussion here but until then here's the log.

OTR4j Authenticated Key Eexchange Log in Chainsaw V2

Screen capture of Chainsaw V2 visualizing otr4j running the Off-the-Record (OTR) Authenticated Key Exchange.

Progress by June 25

It's been a while I haven't update the blog. Well this is all but true for the otr4j library!

I have been working on it during the past 14 days, and I am pretty happy to announce that with the latest changes just a few minutes ago, goal "June 25" has been reached. That is, as of revision 068510f52f otr4j can successfully run an Authenticated Key Exchange, and exchange encrypted data.

Tomorrow I will write new tests and improve existing ones to make sure the implementation is fully functional.

After that I will dive into SIP Communicator and will start working for goal July 05.

Progress by June 11

Did a relatively big code refactoring. First of, I purged some elements that where obtrusive like huge javadocs and getters/setters. Both can be added at a later development stage when the library will be relatively stable.

Simplified how messages are assembled/disassembled. Now one can disassemble a message by calling the appropriate constructor, and can assemble messages by calling the toString() method of a message instance.

Implemented state transition handling and message reply dispatching mechanism when receiving

• Plain text messages (with or without whitespace)
  
• Query messages
• Error messages
• D-H Commit messages
• D-H key messages

Created or adopted existing test cases, for refactored functionality (assemble/disassemble) and new functionality of handling state transitions respectively.

The project now uses Mercurial. Get a local copy of the repository with this command:

hg clone https://otr4j.googlecode.com/hg/ otr4j

Arsenal selection

I feel much more productive in Eclipse, and I also find it less obtrusive so I switched back to it.

A promising plugin, unfortunately not officially supported, for integrating Mercurial with Eclipse exists, and I installed it. IMHO the plugin is very nice and clean (I downloaded the source) BUT -as it usually happens..- I did some wrong clicks here and there and I messed up my source tree..

Then (in a bright moment I guess..) I thought I'd better switch to the command line (, I am aware of TortoiseHg, but I want my terminal back!) where I can have full control of what I’m doing (step by step..). So there I was, back at the beginning, using Eclipse and the command line :D and as I had already lost quite some time clicking around the various windows, I got back to work.

Finally (and thankfully..), I completed my changes and I wanted a tool to compare the diffs. I wanted a tool that would do folder diffing/directory diffing/folder compare/”call it what you like”, because I had done many changes and I wanted an overview picture of them.

I stumbled upon this stackoverflow post which led me to use WinMerge, because it is free, and even better it’s open source! I had to download the setup executable to get it to work because WinMergeU.exe depends on MFC7.1 and I could not find the the Microsoft VC++ 2003 Redistributable Package. The tool works fine, in fact it works great and I liked a lot.

If anyone wants to use WinMerge add this to the Mercurial.ini:

[extensions]
hgext.extdiff =
[extdiff]
cmd.wmdiff = C:\Program Files\WinMerge\WinMergeU.exe
opts.wmdiff = /r /e /x /ub

and then run hg wmdiff

But, (in yet another bright moment I guess..) I thought I’d try SourceGear’s DiffMerge which am used to it’s coloring conventions. This tool has folder diffing/directory diffing/folder compare/”call it what you like” and most importantly, it seemed to be a little faster than WinMerge.

If anyone want to use Sourcegear’s DiffMerge tool add this to the Mercurial.ini:

[extensions]
hgext.extdiff =
[extdiff]
cmd.sgdm = C:\Program Files\SourceGear\Vault Client\sgdm.exe

and run then hg sgdm

That’s all with my arsenal selection. If you ask me, it was a little boring to do all this stuff, but one has to do changes to his development toolset from time to time :-)

Have you checked out some cool features of NetBeans?

I wanted an overall picture of otr4j, so I thought a good idea would be to create a class diagram.

Initially, I checked what's the Eclipse way of doing this. It seems although there are tools for modeling in Eclipse, they don't support reverse engineering source code into UML diagrams, so I thought "this must be something Eclipse developers do with some 3rd party -not very expensive- application..".

I browsed the web for a while, but found nothing standard except from ArgoUML maybe (one should define standard off course..). I eventually settled with NetBeans.

I was aware of the fact that NetBeans has support for reverse engineering Java Applications but didn't consider using it from the beginning because I wanted to build up my existing Eclipse skills.

The good stuff about NetBeans don't end here, it even has Mercurial support by default, which made me want to use Mercurial and let me be productive at the same time. Apparently I was very wrong about NetBeans..

I got so excited that I just made a question in the post where Mercurial support for Google Code has been announced, asking when it will go public. Now that Mercurial is working for me, I want to push my change sets!

Progress by June 04

I think it's about time for another update on the otr4j library development progress..

First of all, a new dependency has been added, the BouncyCastle Java Cryptography Library.

The default security provider fails to generate a D-H KeyPair with a modulus larger than 1024 bits with the following message: "Prime size must be multiple of 64, and can only range from 512 to 1024". OTR uses a specific 1536 bit prime, so incorporating the BouncyCastle library was inevitable.

Furthermore, I have revisited some of the methods for assembling/disassembling the various OTR messages. I mostly changed the method signatures, for example instead of passing BigIntegers and byte arrays, I now pass DHPublicKey or PublicKey interfaces, which seems to be a better choice for cleaner code.

I have also made progress on handling state transitions, but this area still needs a lot of work.

I expect that by June 10 (next Wednesday) there will be proper code structure for state transition handling and that the library will successfully "receive" (through test cases) plain text (with or without whitespace tags), query messages, error messages, D-H commit messages and D-H key messages.

Lastly, I started using Mercurial, so to run the code (the tests) you must have mercurial to import the repository. The code for this preview release is available here.