Running code from strangers

Why anybody would download and run a binary program from a perfect stranger? I was looking at Apache logs to see if somebody was downloading a jar file I uploaded yesterday, when suddenly this question hit me. I did not release the code source because of lack of time to clean it and package it, so the potential users can not check the code source to verify that my program is not a Trojan horse but anyway source code or not, nobody will do a code review. So what can a user do to check that a program is really doing what its author says?

The program is in Java, so the solution is to run it under a security manager. This is really easy – just pass “-Djava.security.manager” to the JVM and any access to a security sensitive resource will throw an exception. Because this is a verification done by the JVM, there is no possibility for the program to bypass this. When the program runs without security manager, I just display a warning message like this:

You should not run random Java programs downloaded from the Internet without security manager.
Use the --help-security option to know how to do this.

Note that running the program under a security manager only one or two times to check that it is not a Trojan horse is not better than doing nothing; if I wanted to do something bad in my program, I would be sure to not do it when a security manager is installed, to not be detected.

Then comes the tedious task of writing a policy file to authorize the program to access the resources it is supposed to access and no more than this. One way of doing this is to add the “-Djava.security.debug=access” to the JVM command line and to add (or not) to the policy file a permission each time an access denied is found. The problem is that one needs to run absolutely all the options in the program to be sure to trigger all the security accesses, which is not very practical. The solution I chose for my program is to add an option that generates the policy file that is needed to run the program with the specific parameters under the security manager. Here’s an example:

$ java -Djava.security.manager -jar id2kindle.jar --generate-policy draft-ietf-behave-turn-uri-01.txt
grant {
  permission java.io.FilePermission "draft-ietf-behave-turn-uri-01.txt", "read";
  permission java.io.FilePermission "draft-ietf-behave-turn-uri-01.zip", "write";
};

The standard output can be redirected to the policy file, which is then used to run the program:

$ java -Djava.security.manager -jar id2kindle.jar --generate-policy draft-ietf-behave-turn-uri-01.txt >id2kindle.policy
$ cat id2kindle.policy
$ java -Djava.security.manager -Djava.security.policy=id2kindle.policy -jar id2kindle.jar draft-ietf-behave-turn-uri-01.txt

As long as the content of the policy file is verified before running the program, nothing bad can happen. Well, excepted that most people will run it at least one time without security manager and one time is all that is needed to do bad things.

Internet-Drafts for Kindle (2)

Yesterday I explained about my efforts to convert Internet-Drafts to a format that is usable on the Amazon Kindle. The solution described is certainly fine for the long-term, but does not help for the IETF meeting in 10 days. So for the short-term, I developed another Java program that takes an Internet-Draft or an RFC in text form and convert it to a series of images that can be displayed on a Kindle. All the nice features of the Kindle like reflow, dictionary, TOC, links, bookmarks, annotations, etc…, do not work with this, but that’s better than printing – and carrying around – 500+ pages. The program is available here:

http://ietf.implementers.org/id2kindle.jar

And can be used like this:

java -jar id2kindle.jar rfc3261.txt rfc3261.zip

The .zip file must be installed directly in a directory named /pictures on the Kindle 2. On the Kindle 1, the file must be unzipped in the /pictures directory.

On the Home menu of the Kindle use Alt-Z to rescan the flash memory and the new document should be selectable. Press J to switch the full page mode.

Formatting Internet-Drafts for the Amazon Kindle

The 74th IETF meeting is coming fast and it is time to start reading the latest version of all the Internet-Drafts relevant to the sessions one plan to attend. I counted 70 documents in my case, and that’s a lot of reading. Printing all this documents is bad for the environment but it is so far the easier way to manage this task especially because it is easy to annotate them directly with a pen. Reading on a laptop is not as convenient and does not make annotations easy.

I was thinking since few IETF meetings that my Kindle would be ideal for this task. It is small enough to be easily carried around, does not need to be recharged as often as a laptop, and permits to annotate documents. Unfortunately the text formatting of an Internet-Draft does not look very good on a Kindle, as it is optimized for text console with 80 columns.

So I wrote a converter that take in input a RFC 2629-formatted Internet-Draft and convert it to a .mobi document that displays nicely on a Kindle. I would have been happy to write an XSLT script for this task but unfortunately the Kindle cannot display correctly tables or some special formatting needed by IETF documents, so I used Java to generate the tables as images. The code is not very smart yet, but I was able to convert my 3 current I-Ds to .mobi files and they can be downloaded here:

http://ietf.implementers.org/

This will not solve the problem of reading all this drafts soon because very few authors upload the RFC 2629 version of their draft to the IETF website, but I hope that this will encourage people to start doing it.

@Syntax

I like programming in Java because it is a strongly typed language, i.e some classes of programming errors are discovered at compile time instead of at run time. The generics feature introduced in Java 1.5 is a great improvement that add another class of errors that can be discovered at compile time but at the same time some additions to the Java languages introduced new potential programming errors that cannot be easily detected at compile time.

The oldest feature with this problem was I think SQL. The SQL requests are stored in String objects and a syntax error can be detected only when the program itself runs – at best it can be detected when the program starts but in the worst case, e.g. if a SQL request is no used very often, it could be discovered too late. Sure it is possible to write unit tests to detect the error, but this a little bit overkill just to verify that the syntax is correct. Other examples of String objects containing structured text are used in MessageFormat, Pattern (regex), Formatter, etc…
So I wrote this small java annotation named Syntax. The idea is to annotate a String containing structured text with the type of syntax used. At compile time, it is then easy to check that the content of the String is valid. Here is the definition of the annotation:

public enum Language { REGEX }

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.SOURCE)
public @interface Syntax {
public Language value();
}

An annotation can then be added to a String constant:

@Syntax(REGEX)
private static final String MY_PATTERN = "[abc";

It is then simple to write an annotation processor that retrieve the value of the String and use Pattern.compile to check the syntax. The implementation for Pattern, MessageFormat, DateFormat and Formatter is only 72 lines. Adding SQL is a little bit more tricky, as there is nothing in the JVM to verify the SQL syntax. A simple solution is to use JavaCC that have free grammars for SQL and other languages.

The main limitation is that this annotation can be used only on a String constant, so the code needs to be slightly rewritten to take advantage of this technique.