I still enjoy research and development but have been spending most of my writing efforts
Here

I will continue to post bit infrequently and the content will become more of a commentary on the IT world than detailed technical articles

Fortunately I am still getting phone calls and have an interview soon for a role in Zurich, perhaps my second favourite location in Europe but have been unable to break into the Hong Kong and SE Asia markets.

This recession appears to be breaking all the rules. Disguised protectionism is rife but clients still outsource jobs to India. There are almost no contract vacancies, whereas in times of uncertainty one would have expected an upswing in the demand for flexible labour.

There are hints the recession is lifting, and recruiters tell me they are busier now than a month ago. Some recruiters may be beginning to worry about their own jobs and are being politer to candidates.

If I had the experience and capital I would team up with an experienced recruiter and go into that side of the business. It seems like something I could do working from home.

I am not alone however. Many vastly more experienced IT contractors than I are having even less luck in the market

http://www.schneier.com/blog/archives/2006/01/countering_trus.html

( I;m too tired to create a link but I want this up before sleeping)

which was the trigger for this post.

Here I will give a high level overview of the defence,, summarising the above mentoned dicussion, and a few ideas how to do cheaper, but possibly less reliable checks. This is a new field for me, so treat what I say with caution.

The trusting trust attack involves altering a compiler so that it introduces malicious code into any program it compiles and puts into itself the code that introduces the malicious code into any non compiler program it compiles.

Wheeler’s technique is devastatingly simple in principle. Compile the compiler with two independently written compilers to produce two versions of the compiler that will be functionally identical and then compile any code you like with each version of the compiler. If the resulting binaries are identical then compiler is almost certainly clean. If they differ at least one compiler is untrustworthy. Here I am taking the compiler to include the linker. The compiler must also be deterministic.

Now I do not see any weaknesses in this defence. The only problem I see is that it might be hard to ensure all the critical code – linker, disassembler, file compare program etc, have been checked. There may also be technical problems in compiling the compiler.

With a suspect JVM or other virtual machine system you must rebuild the JVM with diffetent compilers (someone tell me this is possible I have not had much luck trying to build a JVM from source code) and convert two class files to executables using two native compilers.

So I considered a quick and dirty method for checking at least the compiler etc. These will fail if the system is compromised but may pass if it is. I stop at the point where Wheeler’s technique comes to involve less work

Write hello-world. Compile it, put the object code and executable on a CD and, on a standalone machine with a different operating system examine the files with a hex editor. This will be hard work and will not reveal a problem if the attacker explicitly avoids this defence. If you know what to look for this will reveal any problem. You will also see if the compiler has done any code caving. Oh. yes, Hello-world is small enough that any extra malicious code is likely to result in a suspiciously large binary

On a minimal capacity standalone machine run hello world in a sandbox. Look out for any changes in the system or the hard disk. Check for efforts to connect to the internet.

Now run hello world on a machine that attempts to connect to the internet via a firewall. Configure the firewall to reject any input from your test machine.

However prevention is the best cure and Wheeler noted that the attack depends on recognising a pattern in the source for the compiler. Perhaps another defence would be to reorganise parts of the compiler source to destroy the patterns that would tell the compiler it was compiling itself.

I wonder however whether any trusting trust attack in the wild has ever been implemented. Yes it is a powerful attack but not a fire and forget attack. As I mentioned refactoring of the compiler could remove the patterns on which the attack relies.

In the corporate world where the financial reward for this attack seems greatest compilers are not built from source. There is not enough time for that so once a malicious compiler is intalled it will be used for a long time. Trusting trust is overkill for such a target. Most attackers would find it easier therefore just to provide a malicious binary of the compiler which would infect the programs it creates. A fake gcc download for instance is probably easier to create than a trusting trust download.

Where would a trusting trust attack be worthwhile? The target would be a compiler writing organisation that supplied compilers to the finance industry. The pattern would be to sell the compiler to clients and it back to rake in the money and data. Few organisations could justify the effort involved.

So don’t get paranoid.

So in order to protect yourself against this attack do not trust compiler or JVM, be sure you have the compiler or JVM source, use Wheeler’s Diverse Double compiling technique but assume it will eventually be countered by a smarter attacker, refactor the source a few times and change the compiler compiler from time to time. And use Wheeler’s technique on all the libraries the compiler uses.

It seem to me Wheeler’s defence is a variant of redundant computing. The same thing is done in three ways and the results compared. It involves a lot of work creating a trusted system and ensuring it remains trusted. Most developers, especially those not doing it as a living will not have the time or resources for that. But where security is paramount it will be a valuable tool

© Alex Kashko 2008

There is a school of thought that says,  with some justification that code should be self commenting, that carefully written code should need no comments.  experience shows that this is an ideal and this note is an effort to lay down guidelines for the apparently simple art of commenting code. It was inspired by reading a lot of code where the only comments were autogenerated and said “DOCUMENT ME” and other code where what the code DID was clear but  WHY it did it was not.
It was also inspired by the painful realisation that code  I write becomes less and less obvious the longer it is left unchanged.

When a developer reads  a comment they either have access to the code, or – think Javadoc here – they do not.  While there are differences between the commenting needed for each case there are a  few general rules apply in all cases.

Comments should
1.Be as short as possible but no shorter.
2.Assume the reader is less  skilled than the developer writing the comments
3.Show as much of the big picture as possible.
4.Be meaningful
5.Assume the reader  has limited knowledge of the language in which the comment is written.
6.Be aware, if the comments are in English, that  American English is not British English is not Indian English is not….
7.Show why as well as what

Lets take a simple example of a java method

public static void incrementCounter() { this.counter++;}

Technically this is self commenting, it is clear that the instance variable counter is incremented. However it leaves a lot of questions unanswered. What is the role of  counter for example, so lets start adding comments. First a bad comment.

// Increments the counter

Now lets improve it. Of course I am inventing a hypothetical case as I go along.

// Increments the counter.
// Various methods (specified) reset the counter to zero when it exceeds a threshold

Well this is better but still leaves questions. So we improve it slightly

// Increments the count of the number of failed attempts to contact the server.
// callers may reset this if the count exceeds  the threshold specified for that caller.

Better still we rewrite the method. We still need a comment

//  tracks the number of failed attempts to contact the server.
// Callers may determine the action to be taken for  various values of the counter
public static void incrementFailedContactCount() { this.numberOfFailedContacts++;}

So now we need to consider overflow

//  tracks the number of failed attempts to contact the server.
// Callers may determine the action to be taken for  various values of the counter
public static void incrementFailedContactCount()
{
// reset the counter if it overflows. Should not happen but…
if (1 + this.numberOfFailedContacts) < 0
this.numberOfFailedContacts =0;
else
this.numberOfFailedContacts++;
}

The comment here is for the benefit of the  programmer who has been working all night !!!!!

So how does this meet  the principles above.

1.the comments are short
2.They assume the reader  has forgotten or  did not know about overflow
3.They show something of the big picture
4.They are meaningful
5.They are written in simple English
6.They are written in International English
7.They show why as well as what.

Modern programming is  more and more based on frameworks. This means that a  method may look redundant but not be redundant. For the better known open source frameworks   little or no comment may be needed but a gentle reminder or hint to the less experienced may well be in  order

// Called by the framework in the event of a failed connection.

and so on.

So to summarise and add  a couple more points

1.Keep comments short and meaningful
2.For each major unit  of code ( e.g a class file) write a brief introduction. This would justify the existence of the class for example
3.Try to show where the code fits in the big picture
4.Use neither sophisticated nor vernacular language.
5.Show why as well as what.
6.If you have to explain  what the code is doing maybe it needs simplification.
7.Do not assume the user is stupid, only that they know less than you do or may need reminding of the obvious because they are having a bad day.
8.Refactor code to minimise the number of comments needed.

The bottom line here is that comments are there to help others, as a  record and a mode of communication,

And finally remember.

The life the comment saves may be your own.

A colleague was having problems with a poorly written Eclipse RCP project. So I got the job of taking a simple RCP application and doing what he was trying to do in a real application in an environment that could be presumed to be working.

You will need to have installed and sworn... err stared at the code of the  sample Eclipse RCP application that you can  create from  most Eclipse distributions to follow this note.

So the goal was as follows

1. Generate the Eclipse RCPSimpleMailClient skeleton 
2. Add  and populate a second toolbar to the coolbar ( A coolbar is a collection of toolbars).
3. The second toolbar must only be visible when a message view is visible in the client.

The first two requirements were trivial. The potentially tricky bit was (3). My feeling was that this would need to be done programatically, and could not be done by manipulating the plugin.xml.  This may have been a result of my preference for code  rather than configuration but  investigation revealed no way to do this via the plugin.

At a high level the solution is

1. When creating a view populate the coolbar with all desired toolbars

2. When disposing of the view remove the second toolbar from the coolbar.

This meant I needed to find a way  to make the clients ApplicationActionBarAdvisor  available to the view being created. There is probably a neater way but I chose to create static (class) variables and methods in the ApplicationActionBarAdvisor  and  let the View's createPartControl and dispose methods use these to manipulate the coolbar.

As usual I found a few undocumented peculiarities

Most of the  task was straightforward and doubtless most readers will be ahead of me and included

1. Add static fields to the ApplicationActionBarAdvisor and a static getter for the,

2. Add a static method  fillCoolbar() for use by createPartControl. 

3. Reference  fillCoolbar in create PartControl

4. In dispose() remove the second toolbar. This yielded a small surprise

5. Alter the plugin.xml file when changing the actions needed on the second toolbar

Here is the bulk of the modified code. I  omit the changes to ApplicationActionBarAdviser.makeActions as they involve only initialising static fields.

The convenience method  fillColbar() is

public static void fillCoolBar()

{

ICoolBarManager coolBar = theirCoolbarManager;

IToolBarManager toolbar = new ToolBarManager(SWT.FLAT | SWT.RIGHT);

coolBar.add(new ToolBarContributionItem(toolbar, ID_MAIN_TOOLBAR));

toolbar.add(theirOpenViewAction);

toolbar.add(theirShowtimeAction);

// Add a second empty toolbar to the action bar

coolBar.add(new ToolBarContributionItem(toolbar, ID_SECONDARY_TOOLBAR));

}

variables starting “their” are static variables. 

In the View's createPartControl method  insert a line

		ApplicationActionBarAdvisor.fillCoolBar();

The dispose method is 'interesting' and  a major reason for writing this

public void dispose()

{

ICoolBarManager coolbarManager = ApplicationActionBarAdvisor.getTheirCoolbarManager();

IContributionItem removed = coolbarManager.remove(ApplicationActionBarAdvisor.ID_SECONDARY_TOOLBAR);

// THE INTERESTING THING IS THAT YOU NEED TO DO THE UPDATE TWICE

coolbarManager.update(true);

// ArrayList<String> idList = new ArrayList();

// idList.add(ApplicationActionBarAdvisor.ID_SECONDARY_TOOLBAR);

// DOES NOT WORK IF YOU REMOVE THELINE BELOW

coolbarManager.update(true);

ApplicationWorkbenchAdvisor.theirConfigurer.setShowCoolBar(true);

}

• The first line just gets the application's stored IcoolbarManager

• The next line removes the second toolbar

• The line after that updates the coolbar manager. Unless I missed something the Eclipse API documentation does not state that update(true) is needed to see the effects. I understand why they did that but it took me a few minutes to work out why I was not seeing changes in the coolbar.

• The second update is needed but I have no idea why and no intention of trying to find out.

• The final line  just guarantees the coolbar is visible.

The next stage was straightforward. I decided to create a modification of the message popup action that would show the date and time. Nothing fancy but better than “Hello World”

So I created a new Action called ShowTimeAction which was almost an exact clone of MessagePopupAction , registered it in the makeActions() method and  altered the ShowTime constructor to use a new image

ShowTimeAction(String text, IWorkbenchWindow window) {

super(text);

this.window = window;

// The id is used to refer to the action in a menu or toolbar

setId(ICommandIds.CMD_SHOW_TIME);

// Associate the action with a pre-defined command, to allow key bindings.

setActionDefinitionId(ICommandIds.CMD_SHOW_TIME);

setImageDescriptor(com.example.rcpapp.Activator.getImageDescriptor(“/icons/showtime.gif”));

}

The changes are the change of ID and  image descriptor

This finally required a change to the plugin manifest plugin.xml
And all I needed was to add a new view in the plugin.xml

<view

name=“Time”

allowMultiple=“true”

icon=“icons/showtime.gif”

class=“com.example.rcpapp.ShowTimeAction”

id=“com.example.rcpapp.showtime”>

</view>

At this point everything was working perfectly.

That is when I discovered that the problem my colleague had was a different problem from the one I had been told he had. But that is (a) Life and (b) a different story

Branding Eclipse: Notes for the puzzled

© Alex Kashko 2008

I  recently got the chance to work on an Eclipse plugin project. Since it was something I had never done before I was delighted.  Eclipse being a host of plugins  all cooperating (exceot the ones I  inherited to work on did not) I expected to gain insight into aspects of eclipse I had never before needed to know.

I expected problems due to  lack of experience and was not disappointed. One little problem I found was with Branding.

The Eclipse IDE is a marvellously complex beast. One of the features it offers is the ability to create a product that does not look like Eclipse, at least to the uninformed Eye

I wanted to know how to create and personalise an Eclipse product and, not wanting to mess up a working project with experimentation, I started with the sample RCP mail application in Eclipse Ganymede and followed the RCP tutorial on the Eclipse site.

Everything went well till I started trying to change the splash screen and the image on the ‘about’ tab.

One of two things happened. Either the images did nto change or they appeared when launching the application from Eclipse but did not appear in the exported product.

It also seemed impossible to use images with different names from the standard Eclipse ones. I ended up theorising that the export process got confused if there were more than one .bmp or.gif file in the root directory.

I found some reports of very similar problems via google. This led me to speculate that either there was a bug in eclipse. Or more likely the tutorial and other documentation had missed something out.

Eventually I found a way to get this simple task working. I deleted the splash.bmp and product_lg.gif files and imported new ones. Then I exported the project ( making sure the synchronise box was checked) and everyting worked. This was on my home machine not my work machine.

The problem still occurred on my work machine even when I followed the procedure that worked at home. After a few minutes I discovered that somehow the two image files had been deselected in the build.properties file.

Now I have a properly branded product and more importantly knowledge of what the Eclipse documentation does not tell you.

It seems (and I will use this as a working hypothesis till it breaks down) that you need to examine the build.properties file includes your images before you export the product. Deleting and reimporting splash.bmp worked on Europa under OS X but on Ganymede under XP the process seems to have removed the files from build.properties.

So the procedure I will adopt for branding in future is

1. Try to do the branding before doing any serious work

2. When creating a product configuration do not be clever. Accept wizard defaults.

3. Check the build.properties file has all the image dependencies before exporting

4. When re-exporting a product delete the old export or use a new directory.

5. Check size limits.

I looked again at the Hibernate Tutorial and now I have a better idea when not to use Hibernate, at least in its present state (Hibernate 3).

The Open source frameworks I have been looking at (Hibernate, Spring) and Java Server Faces and JSP seem to me to simplify Java coding at the cost of more complex XML based configuration files. This has long been a grumble of mine since the structure and construction of the xml files is seldom explained. I searched a number of books on EJB before finding one that explained the multiple horrors of the XML files that needed to be configured and I instantly purchased it. Unfortunately I do not have that book any more ( Its a long story).

On the Java side Hibernate claims to remove the need for knowledge of SQL but it seems that HQL ( Hibernate Query Language) may often be needed. So this benefit is perhaps over stated. More importantly Hibernate requires the Developer to have a knowledge of the Database Schema, perhaps even design the schema. To my mind the developer should be able to work without worrying about the database.

On a project I did last year the Developer was insulated from the database because access to the database was purely through stored procedures. Once the interface was stable “all” that was needed was to write JDBC code that called the desired stored procedure and took the appropriate action when the procedure had returned a value. This approach showed its value when the entire database had to be redesigned for performance reasons. There was zero impact on the Java developers, namely me. So while the database team were sweating away I was tidying up and commenting my code to help the maintenance developer. Who could have been me, had events turned out otherwise ( A downturn in company share price led to a lot of budget cuts).

As I recall prior to Hibernate 3 it was not possible to call stored procedures from Hibernate. Version 3 imposes some restraints on the stored procedures. Had we used Hibernate 3 a reorganisation of the database would have had a major impact on the project.

A quick look at sample code on the Hibernate site seemed to show that calling stored procedures from Hibernate is of the same level of complexity as from JDBC. Together with the rules Hibernate imposes on the design of stored procedures this means Hibernate offers little or no benefits over JDBC. The extra XML configuration over load currently tilts the balance of benefit towards JDBC.

Experience may make me revise these conclusions but I think Hibernate is still a good replacement for entity beans with simple database schemata. However it seems to me that the need for the Java Developer to know about the internals of the database rather than just a stored procedure name and signature poses maintenance risks and could impact deadline and budget if a major change to the database became necessary. It can be argued that the use of XML files allows metadata to be stored outside the Java code and this makes it easier to change if necessary. I accept this, but I think in a lot of cases a carefully designed property file will give similar flexibility but I recall an architect telling me that the problem with putting things into XML is that, as with reflection, the compiler cannot help you avoid bugs. He was talking about Spring but I think the problem is common to a number of XML based frameworks. The answer of course is more rigorous testing and careful monitoring of changes to the XML especially when a single character can change the meaning of a caption that may be displayed to a client ( mistyping “count” for example).

Eventually Hibernate is likely to overcome what I see as shortcomings and risks, and then it may be seen as too complicated, and another open source framework will take its place. Till then I congratulate the developers on their achievement and hope they keep improving it.