From Actions to Commands

I moved from Actions to Commands lately for all XML Security Tools operations. Except some removed icons, the XML Security context menu doesn't look much different. So why all the work (or trouble)? Well, Commands are much cooler: clean separation of UI and business logic, and therefore reusable. Yes, it's possible to reuse Actions too, simply duplicate the code…

The main reason for the change was to integrate closer with the rest of the Web Tools Platform. The XML Security extension is now available in the Package Explorer, Project Explorer and Navigator view, but only in the XML perspective. The editor extension (the same menu) is available in the WTP XML editor at all times (in any perspective). Achiving that is much easier with Commands (Menus and Handlers) than with Actions.

The layout changes should make it easier to use the XML Security Tools commands. The menu entries with icons use the regular wizards and require much user interaction. The menu entries without icons are the so called quick functions with minimum user interaction.

The next step is to provide a simplified menu in the XPath view: after entering an XPath expression simply select the desired resulting element and choose sign or encrypt. The XML Security wizard should already take into account which element is selected. This is not done yet, see BugZilla for my progress on that. And I'm working on the documentation, the English version in the Eclipse wiki, the German version as tutorials on my home page.

The latest XML Security Tools version is available on the WTP Incubator download page. The promoted version available here does not include the latest changes. The next integration build on this site will be available after the English documentation is completed. So visit the committers download page for continuous updates and the WTP download page for more or less stable integration builds.

JCrypTool 1.0.0 Milestone 5 available

JCrypTool 1.0.0 Milestone 5 is finally available for Linux, Mac and Windows systems on our download page. Be aware that it is not possible to use the update manager in Milestone 4a or older to update to the new version. We are sorry for the inconvenience, but there are more changes included in Milestone 5 than the update manager can handle (mostly p2 related). So please download the complete archive ones more.

See the JCrypTool 1.0.0 Milestone 5 – New and Noteworthy page for an overview of the new features and updates.

Reasons for the delay? Well, it took us much more time than expected to include p2. There were a lot of pitfalls, and we jumped from one to another.

But nevertheless, this milestone moves us really close to the final version 1.0.0, only one more milestone should follow the next months. Milestone 6 is already scheduled for November, depending on the time we are feature complete. There are some open tasks so far: Actions View is incomplete, Command Line is completely missing and the online help is not as complete as it is supposed to be. The first steps Cheat Sheet is not completed yet too. Those tasks must be contained in milestone 6, before we enter the endgame and release our first release candidate. So there is still enough to do.

Your feedback, ideas, wishes and bug reports are as always welcome, so feel free to contact me or use the forum on our home page.

Running an Eclipse RCP on Mac OS X Snow Leopard

Since I have updated to Snow Leopard lately I ran into the JVM 64 bit problem. SWT is simply not available for Mac OS X with 64 bit. This hit me when launching JCrypTool the first time after updating. The solution to fix this is to add -d32 as a VM argument for in the run menu entry and voilà, the RCP is running again.

Eclipse RCP – exporting for multiple platforms

In case you want to deploy a feature based RCP for more than one platform (with the delta pack): Do not forget to add the org.eclipse.rcp feature either as included feature to one of your features or add it directly to your product configuration. The org.eclipse.rcp feature includes all the platform dependent plug-ins and fragments (like SWT win32). So in case your export doesn't contain the platform dependent files (and fails to launch) verify that this feature is added…

Even if you do deploy to one platform only but do have a feature based RCP you have to add the org.eclipse.rcp feature. Otherwise you have to add all required platform dependent fragments yourself.

HMAC truncation authentication bypass in XML Signature

There is a vulnerability with XML Signatures. The W3C recommendation includes support for HMAC truncation, as specified in RFC2104. The thing is, this support is not complete: The RFC does not allow truncation to less than half of the length of the hash output or less than 80 bits (whatever comes first). The XML Signature recommendation ignored this part of the RFC up to now. So when HMAC truncation is under the control of an attacker this can result in an effective authentication bypass.

On one side this is serious since it is possible to specify an HMACOutputLength of 1, so that only one bit of the signature is verified. This can allow an attacker to forge an XML Signature that will be accepted as valid. US-CERT lists the vulnerable products. Apache XML Security up to version 1.4.2 is vulnerable (among a lot of other products). Since version 1.4.3 should be available tomorrow (including a fix for this bug) at least Apache XML Security users will be on the safe side again. And on the other side the HMACOutputLength feature is not that widely used, so there is no need to panic.

The upcoming XML Signature 1.1 recommendation is already updated. See the Q&A page contains some additional information.

Using Eclipse SWT.SEARCH

After reading Prakash G.R. great blog posts (here and here) about the Eclipse search field I have submitted some updates to the algorithm search in JCrypTool. And noticed some additional things which are in my eyes quite important when using SWT.SEARCH.

What happens in JCrypTool when using the algorithm search is that the Algorithm view gets updated in real time, so the search works as a filter. When clicking the x icon the filter should be set to empty, and the view must display all elements again. But the default clear action is to empty only the search field. Fortunately this is as easy to extend as mentioned in Eclipse Javadoc:


Text search = new Text(parent, SWT.SEARCH | SWT.CANCEL);
search.addSelectionListener(new SelectionAdapter() {
 public void widgetDefaultSelected(SelectionEvent e) {
  if (e.detail == SWT.CANCEL) {
    // action when clicking on the x icon
  }
 }
});

You have to use the widgetDefaultSelected method in case you need to do more than just clearing the user input. Remember that the SWT.CANCEL check is only possible when using SWT.SEARCH | SWT.CANCEL as options for the text field.

The really sad thing is (at least for Windows users), such a stylish text field is only available on Mac, but not on Windows (at least Windows XP does not support it). Since I am a happy Mac user I have no idea about Linux. At least the search text field is shown as a normal text field when it comes to Windows (better than being invisible or unusable at all). So it is necessary to provide an additional clear icon when the operating system does not support the clear action inside the text field. Simply implement the following check after creating the search text field:

if ((search.getStyle() && SWT.CANCEL) == 0) { }

Put all actions and GUI elements for antiquated operating systems in this block and you are done. Since the return code on Mac is different this part won't be executed on Mac systems and therefore only the stylish text field is visible.

Update, 2009-07-19:
With Eclipse 3.5 you should initialize the search text field in this way:

Text search = new Text(parent, SWT.SEARCH | SWT.ICON_CANCEL | SWT.ICON_SEARCH);

On Mac this offers an additional search icon in the text field. The Eclipse 3.5 M6 News contain the information, that this style is now available on all platforms. I wasn't able to confirm this with JCrypTool, the only supported platform I'm aware of is the Mac.

JCrypTool milestone 5 development update

It’s been a while since I last blogged about the upcoming JCrypTool milestone 5. Time for an update.

Milestone 5 is still scheduled for end of July/ beginning August. No exact date yet, still too far away. New implemented features up to today are a web browser plug-in and a lot of extensions to existing plug-ins: The File Explorer view provides more file operations, the Algorithms view offers drag&drop and some other improvements and the overall extensibility of JCrypTool has been enhanced. And yes, there is more documentation available, for end users and for developers (still more to come). Welcome Page and sample files are updated and provide a much better first impression of JCrypTool now.

On the other side we fixed a lot of bugs and improved the overall performance. There are still some bugs open, which must be fixed for the next milestone (see our bug tracker).

Ongoing work at the moment affects the new Action view, which is only partly implemented so far. This view will be finished for milestone 5. As well as the upgrade to Eclipse 3.5 and the switch from the old update manager to p2. Other features may be rescheduled to milestone 6.

Eclipse help and the dynamic help view

Writing help files for an Eclipse RCP is easy. Help content is simply provided as normal html files. And of course it is possible to format the html code using css. The problem now is, that help view and help browser use the same css, but the view is of course much smaller.

To solve this you need to provide a plugin_customization.ini (defined as a product property in your plugin.xml). Provide at least two parameters for your help files here:
org.eclipse.help.base/topic_css=/de.xmlsicherheit.help/resources/book.css
org.eclipse.help.base/narrow_css=/ de.xmlsicherheit.help/resources/narrow_book.css

topic_css is used for normal help pages, narrow_css only for the help view or help tray.

There are two more parameters available, see the Product customization help page for more information about them.

Another benefit is that all your help pages will look the same. Simply do not integrate any other css style (or make sure you do not overwrite the injected styles) and wait for the help runtime to inject the matching css styles.

Integrating help in an Eclipse Rich Client Platform

Integrating help into an Eclipse RCP does not require a lot of work. Simply use the ActionFactory to add the help menu item to an existing menu in your ApplicationActionBarAdvisor class:

IWorkbenchAction helpAction = ActionFactory.HELP_CONTENTS.create(window); // in makeActions(IWorkbenchWindow window)
register(helpAction); // registration is required
menu.add(helpContentAction); // add it to the desired menu

And voilà, the help menu entry is visible. Click on it, and nothing happens… The reason is easy to guess, the Eclipse help plug-ins are missing. Since the help system changed quite a lot with Eclipse 3.3, the list of required plug-ins differs between the different Eclipse versions. So the following applies to Eclipse 3.4 only.

Some of the required plug-ins are easy to guess:
org.eclipse.help
org.eclipse.help.base
org.eclipse.help.ui
org.eclipse.help.webapp

Doing a dependency check on those (with the Validate Plug-ins button in the run configuration) brings up quite a long list, which really blows up your RCPs’ size. OK, some of them are required by the RCP anyway. While some of the required plug-ins are obvious, others are not:
javax.servlet
javax.servlet.jsp
org.apache.commons.el
org.apache.commons.logging
org.apache.jasper
org.apache.lucene
org.apache.lucene.analysis
org.eclipse.equinox.http.jetty
org.eclipse.equinox.http.registry
org.eclipse.equinox.http.servlet
org.eclipse.equinox.jsp.jasper
org.eclipse.equinox.jsp.jasper.registry
org.eclipse.osgi.services
org.mortbay.jetty

In case you do have a plug-in based product configuration you can simply add the required plug-ins. In this case make sure that the checkbox for the optional plug-ins is selected before clicking the Add required plug-ins button. Or use your run menu entry to add the required plug-ins for you.

Before launching your RCP again make sure that at least one of your plug-ins does provide some help content. Otherwise the help system will show up empty.

Now that we do have a working help system, let’s open some help pages directly. This may be necessary in an Eclipse Form based editor (like the Plug-in Manifest Editor) where a help icon in the upper right directly accesses the help system.

Simply create a command with a contribution item (or an action if you like the old style) and place the following code in the run method:


PlatformUI.getWorkbench().getHelpSystem().displayHelpResource("/de.xmlsicherheit.sample/help/overview.html");

de.xmlsicherheit.sample is the plug-in id as defined in the manifest. Do not forget the leading slash! Now a click on the button, icon or whatever you decide to use will open the help system and directly jump to the desired page. The table of contents should expand itself automatically.

That’s it. As you can see, providing help inside a rich client is easy, once you do know which plug-ins are required.