Parkeisenbahn, Luxembourg

Validating the Android 4.2.2 RSA fingerprint

Android 4.2.2 comes with a new security feature. If you try to connect to your smartphone via adb and USB debugging, you will note that your device is marked as "offline". Additionally, a dialog shows up on your device, presenting an RSA fingerprint of your computer and asking for confirmation to accept a connection.

The rationale is that if your device is lost or stolen, there is no way to read its content even if USB debugging was enabled.

Now, presenting an RSA fingerprint surely is a nice idea to avoid man-in-the-middle attacks. But how do you get that fingerprint in order to compare it with the one shown on the device? At first I thought there must be a command (or an adb option) that prints out the fingerprint, but I wasn't able to locate one. After spending some time with my favourite search engine, I finally dug up a rather more than less complicated command line that prints out the footprint:

awk '{print $1}' < adbkey.pub | openssl base64 -A -d -a | openssl md5 -c | \
  awk '{print $2}' | tr '[:lower:]' '[:upper:]'

The command must be executed in the directory where adb stores the adb key, which usually is ~/.android (or /root/.android if adb runs as root).

If you are somewhat security paranoid, you surely wonder why, on the one hand, Google shows a footprint on the device, but on the other hand makes it difficult to find out if that footprint actually belongs to your computer.

maven-release-plugin and git fix

After hours of trying and wondering why my release scripts suddenly stopped working, I found out that maven-release-plugin seems to have an issue with git on recent systems. If you invoke mvn release:prepare and find out that the release process just runs against the current SNAPSHOT instead of the release version, you likely stumbled upon bug MRELEASE-812.

The reason for this issue seems to be that mvn release:prepare parses the output of git status. However the status is localized in recent versions of git, and maven-release-plugin fails to parse the localized output.

The coming fix will probably use git status --porcelain, which returns a machine-readable output. However, for the time being

LANG='en_US.UTF-8'
mvn release:prepare

is a valid workaround.

Cilla source code released

Finally, after almost three years of development, I have published the source code of Cilla. Cilla is the software that runs this blog.

I started working on a new blog software on June 3, 2009. It should replace my old home page made with PHP. I decided to write an own blog software in Java, as there was no open source Java blog software that suited my needs. However I never expected that this project would grow that huge. The core modules alone consist of 27,000 lines of code in 295 classes.

The core modules of Cilla are now available on my development site shredzone.org. The source code is published on GitHub. The documentation, a few plugins, and a simple example web frontend are still missing. I will publish them later.

Cilla is published under a GNU Affero General Public License.

hibernate3-maven-plugin fails with Java 1.7

If you're using Maven's hibernate3-maven-plugin for creating a DDL file from your entities, you might encounter the following error when using Java 1.7:

Execution default of goal org.codehaus.mojo:hibernate3-maven-plugin:2.2:hbm2ddl failed:
An AnnotationConfiguration instance is required

The reason seems to be a broken JRE detection in the Mojo code, which mistakenly assumes that Java 1.7 does not support annotations. However, I haven't checked that in depth.

The fix is pretty easy. In the plugin configuration of the hibernate3-maven-plugin, add an implementation property to the componentProperties like this:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>hibernate3-maven-plugin</artifactId>
  <version>2.2</version>
  <configuration>
    <componentProperties>
      <implementation>annotationconfiguration</implementation>
    </componentProperties>
  </configuration>
</plugin>

This enforces the use of an AnnotationConfiguration instance.

Setting a renderer on JComboBox

When setting a custom renderer to a JComboBox, the usual way is to extend a DefaultListCellRenderer and override the getListCellRendererComponent() method. However, this may lead to ugly comboboxes on some Look and Feels. As you can see on the top combobox, it is rendered considerably smaller and with the letters sticked to the left border, just by using a DefaultListCellRenderer. The Look and Feel seems to use a special renderer class for proper rendering, as it is shown in the combobox below.

A solution is to use a proxy ListCellRenderer instead, which only converts the value and then delegates the rendering to the original renderer. For example:

public class ListCellRendererProxy implements ListCellRenderer {
  private final ListCellRenderer delegate;

  public ListCellRendererProxy(ListCellRenderer delegate) {
    this.delegate = delegate;
  }
  
  @Override
  public Component getListCellRendererComponent(JList list, Object value,
                int index, boolean isSelected, boolean cellHasFocus) {
    // modify the value here...
    return delegate.getListCellRendererComponent(list, value, index, isSelected, cellHasFocus);
  }
}

The renderer proxy can be used like this:

JComboBox cbx = new JComboBox();
ListCellRenderer oldRenderer = cbx.getRenderer();
cbx.setRenderer(new ListCellRendererProxy(oldRenderer));

The combobox items are now converted to a string by a custom cell renderer, but are still rendered by the original renderer implementation of the current Look and Feel. However, while a single DefaultListCellRenderer instance can be shared with many JComboBox, a new renderer proxy needs to be instanciated per combobox.