Encrypted CVS Repository

We currently have a client that's very concerned with Information Security. It's a multinational company, and we're dealing with its Indonesian subsidiary. Its head office periodically performs scans throughout their subsidiaries' networks across the world, and identifies any possible information security breach. The problem is the network scans prove that when someone has read-access to the CVS repository file, he/she can immediately (without any significant effort) browse through the contents of our source codes.

They require us to propose for an immediate solution to the problem. Apparently, having the CVS access security (through encrypted password) and CVS data transfer security (through SSL) are not enough. We are required to prevent the exposure of CVS repository contents even when the CVS repository file itself has been read. David A. Wheeler mentioned this on his SCM Security article.

We currently have two project teams working at the client site. The first project uses CVS whereas the other uses Subversion. We will be having our third project at the client site within the next few weeks. I'm encouraging the third project team to use Subversion instead of CVS. So, considering the importance of this client, it's very important for us to come up with a solution.

After searching through the net, Greg A. Woods mentioned that it's not how CVS was designed. I've tried to search through Subversion site, and I cannot find any information whether Subversion support encrypted repository or not.

Then, it was Thomas Deselaers’ idea that I believe to be a viable solution.

My plan is to find a good open source CVS client implemented in Java. Then, I’ll intercept the commit command (encrypt line by line), and intercept the update command (decrypt line by line). Ensuring also that the encryption is a basic one (probably XOR operation on each character), I’ll have the merge command unmodified.

So, the end result is, the developers will see the un-encrypted source code at their local development environments, whereas the CVS repository will keep the encrypted source code. The diff command will show the diff of the encrypted lines, though.

Anyone has better solution for this?

Reading a character from the Console

Reading a character from the Console should not be a problem. I hadn't had that problem using C++ back in the college days, but somehow it's not that easy in Java. I have never found the need for it myself, but someone at the local JUG mailing list apparently needs it.

Java has always have the problem of reading a character from the Console, without buffering and echoing back to the Console. This has been an outstanding bug for so long, and it's said to be fixed on Mustang. Well, the bug is really about masking password input, not about un-buffering the character inputs. So, my friend there is not really getting his needs fulfilled.

Someone from the mailing list replied with a link to JCurses. So I tried it. I tried Enigma as well, but it doesn't seem to get the job done.

Here's the code:
import jcurses.system.InputChar;
import jcurses.system.Toolkit;

public class Console {
  public static void main (String[] args) {
    while (true) {
      InputChar c = Toolkit.readCharacter ();
    System.out.println (
        "you typed '" + c.getCharacter() + "' (" + c.getCode() + ")");

      // break on Ctrl-C (3)
      if (c.getCode() == 3) break;
    }
  }
}

It's quick & simple. Part of another surprise, there are some other bugs that still remained till Tiger release. The list includes not being able to change working directory.

What's the most irritating bug of JDK that has not been fixed, according to you?
Does the voting mechanism for bug fixes really work?

Understanding Fluent Interface

After reading Martin Fowler's post regarding fluent interface, I try to write small trivial implementations to understand the concept. Here are the common interfaces of Customer, Order & OrderLine classes, as required by Martin's "makeNormal" method:

Customer
  +addOrder(Order): void

Order
  +addLine(OrderLine): void
  +setRush(boolean): void

OrderLine
  +OrderLine(int, Product)
  +setSkippable(boolean): void

It's quite standard for OO design. Looking at Martin's "makeFluent" method, we need the following interfaces, which I've added some trivial implementations to help understanding the concept:

Customer
+newOrder(): Order
{
  Order o = new Order ();
  this.addOrder (o);
  return o;
}

Order
+with(qty, productId): OrderLine
{
  Product p = Product.find (productId);
  OrderLine line = new OrderLine (qty, p);
  this.addLine (line);
  line.setOrder (this);
  return line;
}
+priorityRush(): Order
{
  this.setRush (true);
  return this;
}

OrderLine
+with(qty, productId): OrderLine
  //note: return the last order added, instead of this
{
  Product p = Product.find (productId);
  OrderLine line = new OrderLine (qty, p);
  this.order.addLine (line);
  line.setOrder (this.order);
  return line;
}
+setOrder(order): void
{
  this.order = order;
}
+skippable(): OrderLine
{
  this.setSkippable (true);
  return this;
}
+priorityRush(): Order
{
  this.order.setRush (true);
  return this.order;
}

Looking at the above sample implementation codes, we need to design additional interfaces to help the client usage be more fluent. Things I've noted:
1. Fluent API can only be applicable for highly used API, otherwise the investment of designing the API may not be as effective as intended. Thus, not all API can be made fluent.
2. Fluent API may be good for "feature-envy" code smells. Feature-envy is when a "client" method calls methods on another class three or more times.
3. Fluent API is suitable for frameworks, e.g. Hibernate, libraries, e.g. Jakarta Commons, or related OO classes (as in Martin's example). But, the timing for designing Fluent API for OO classes is still a big question. If we design it too early, there may be useless API (or the API is not fluent enough). If we design it too late, the ROI may not be as expected.

The pendulum is still swinging.. :D
I hope I can think this through the week, and let you guys know what I think..