OpenCM is a secure open source configuration management system. Supported by contracts, mostly from the Air Force and other DoD organizations, the primary intent of OpenCM is to create something to replace CVS, particularly in security conscious projects like EROS. OpenCM is developed primarily at SRL (which is a subgroup of JHUISI and the computer science department at JHU), though several other people have contributed reasonably large amounts of code. In particular, the OpenBSD project is pretty interested in OpenCM because of it's assurance guarantees, and several OpenBSD people (particularly Todd Fries) have done fairly extensive work on OpenCM (including the IPv6 support).

Why is OpenCM secure? (Or rather, why is it claimed that OpenCM is secure). First, authentication is done very sensibly (contrast with CVS's methods). In particular, someone does not need an account on the host machine in order to interact with OpenCM, because OpenCM does not use the system's password mechanism. Instead, self signed X.509 certificates are used to authenticate users.

All network communications are protected by SSL. Because the user's certificate is used as part of the SSL communication, we can be (reasonably) sure that the stuff we're getting over the wire came from them. For example, someone messing around on the network would have a hard time altering a file in transit without being noticed.

And now to explain the big reason OpenCM is more interesting and potentially more secure than other configuration management systems. But first we'll need a bit of terminology. There are essentially two kinds of objects OpenCM understands, entities and mutables. Entities are frozen, static objects; once they are created they never change - ever. In contrast, mutables are things that can change from time to time.

Now the interesting part: entities are named by the hash of the contents of that entity (called the truename). Because a secure hash function (SHA-1, specifically), is used, there is no way that anyone can guess or figure out the truename of an entity unless a) they already know the contents of that entity, or b) someone tells them the truename. In addition, the use of hashes means that nobody can replace a file out from under you. Even if you ask the server for a particular file, and it gives you one that is just slightly changed, it is easily detectable.

Whenever someone uploads a new copy of a file, that's a new entity. The old entity is not removed, it is around permanently. In addition, because the filename is just one more attribute of the entity, not an intrinsic identifier, file renaming and moving works much better than it does in CVS. As an experiment sometime, try checking out a tree as it existed 5 years ago. More likely than not, it will be useless - CVS will get hopelessly confused about what is what and end up mixing and matching various versions of the system together.

Mutables are, basically, anything that's not an entity. Some examples include Change objects, which basically contain all the information about a particular revision: what files were in it, who made the change and at what time, and so on. Mutables are signed by the server's private key, which provides quite reasonable authentication that the mutable is legitimate.

Some technical trivia: OpenCM was originally written in C++ but was later converted to C. It uses a garbage collector to make memory management a little easier, which is nice for us poor programmers. It uses an RPC protocol over TCP/IP (with SSL in between, natch). The serialization and RPC mechanisms are unique to OpenCM (which I am not a fan of because this way you have to support it forever, but that's how Shap did it).

You can find out a lot more about OpenCM at, including PDF copies of several papers published at Usenix and other conferences (these explain the OpenCM system in much more detail than I have here). In addition you can download the OpenCM source code, which runs on most common Unix flavors, along with MacOS X and Cygwin.

Log in or register to write something here or to contact authors.