posted by Thomas Leonard on Tue 16th Jan 2007 00:32 UTC

"Publishing Software, Sharing Installed Software"

Publishing software

The simplest way for a programmer to distribute software is as an archive file containing the program's files. This archive can be placed on a web page, along with instructions on how to download and run it.

This isn't very convenient. At the very least, we will expect our computer to check for updates periodically and give us the option of installing them. We will also want the system to download and install any missing dependencies we require. Both of these tasks require a machine-readable version of the web page, and there are two similar file formats available for this purpose.

Luau and the Zero Install feed specification both define XML-based formats for describing available versions of software and where to get them. They are rather similar, although Luau feeds don't provide information about dependencies and don't have signatures, while Zero Install feeds don't provide messages about what changed between versions.

Feeds link to versions

A more subtle difference is that each version in a Luau feed contains a cryptographic digest of the package's compressed archive, while Zero Install feeds give a cryptographic digest of the package's uncompressed directory tree. The Monotone documentation has a good explanation of how this can be done, although the manifest format it describes is not identical to the Zero Install manifest format.

While either type of digest is sufficient to check that a downloaded package is correct, Zero Install's digests also allow installed packages to be verified later, and permit peer-to-peer sharing. This doesn't work if you give the digest of the archive, since the archive is thrown away after installation. Of course, there's no reason why both can't be provided, giving an extra layer of security.

Java Web Start's JNLP is another XML-based format with similar goals, but only works with Java programs. Also, the JNLP file and all the jar files (libraries) must be signed with the same certificate, which isn't suitable for the distributed OSS development model.

Sharing installed software

We saw above that letting users install software and having it shared between them was possible (and safe) provided that they were able to put genuine versions of programs in the shared directory, but not incorrect ones. There are two ways we can achieve this.

The first is to have users ask a privileged system process to install a program, giving it the program's globally unique name. The system downloads the named software and unpacks it into a directory with that name. So, Alice can ask the system to install http://gimp.org/gimp or http://evil.com.gimp, and the system will install to /opt/gimp.org-gimp or /opt/evil.com-gimp as appropriate. Alice cannot cause one to appear in the other's location, so Bob can be confident that /opt/gimp.org-gimp really is the program he wants. This is rather similar to the way a local caching web proxy works:

The trusted system downloads the packages

The second approach is to have users download the software and then ask the privileged system process to copy it to the shared cache. This requires the program's name to be a cryptographic digest of its contents, as explained above.

The users download the packages and give them to the trusted system

Which method is best? An early filesystem-based version of Zero Install used the first method, while the current one uses the second. The main disadvantage of the first method is that the privileged process is rather complicated, and this is not a good thing for a program which runs with higher privileges than the person using it, since it's easier for a malicious user to find bugs to exploit. After all, the process must download from the network, provide progress feedback to the users downloading the package, allow users to cancel their downloads or select a different mirror (but what if two users are trying to download the same package?), and so on. In particular, it is not possible to share software installed from a CD when using the first method.

Using the second method, the privileged process only needs to be able to check that the digest of a local directory matches the directory's name. For example: Alice goes to gimp.org and discovers that the version of the Gimp she wants has a SHA256 digest of "4fa...". She sees that the directory /shared-software/sha256=4fa... already exists on the computer (perhaps Bob added it earlier). Alice runs this copy, knowing that the installer wouldn't have let Bob put it there under that name unless it had exactly the same contents as the copy Alice wants to run.

Table of contents
  1. "Introduction, Use Cases, Traditional Distributions"
  2. "Naming, Conflicts"
  3. "Avoiding Conflicts, Dependencies"
  4. "Publishing Software, Sharing Installed Software"
  5. "Security"
  6. "Compiling, Converting Between Formats"
  7. "Summary"
e p (8)    76 Comment(s)

Technology White Papers

See More