Making OpenBSD Binary Patches With Chroot

Lawrence Teo writes "Unlike other operating systems, patches for the OpenBSD base system are distributed as source code patches. These patches are usually applied by compiling and installing them onto the target system. While that upgrade procedure is well documented, it is not suitable for systems that don't have the OpenBSD compiler set installed for whatever reason, such as disk-space constraints. To fill this gap, open source projects like binpatch were started to allow administrators to create binary patches using the BSD make system. This article proposes an alternative method to build binary patches using a chroot environment in an attempt to more closely mirror the instructions given in the OpenBSD patch files."

Why not copy-on-write?

[Anonymous Coward]

The article describes a technique which is in large very inefficient, and wasteful. It is analagous to the notion that a process must be completely copied on fork, however this is not true. Typically the pages used by a child process are copy-on-write, and are only duplicated as the child writes to them. To see the analogy, consider that the article describes this basic process:

(1) Create a new directory (the author creates something in /var).
(2) Unpack a brand new OpenBSD distro and source distro to this directory.
(3) chroot this directory as /
(4) Create a timestamp file using touch (the author calls this a "cookie").
(5) Unpack the modifications to the dummy system. Scripts which refer to absolute path names will work now.
(6) Create a timestamp file using touch.
(7) using find, collect all files that were modified during the time the first and second cookies were made into a tar ball.

This is analagous to copying an entire system, then working on the copy. Rather, why not using a unioning file system? Mount the file system as a unioning file system, thus when a write occurs on a file, it will actually not be modifying the system file system, but a dummy file system, mounted in /tmp or where ever. Once the patch is complete, collect all modified files (the file system will read from the dummy file system automatically) into a tarball as before. This technique has several advantages:

(1) You don't have to re-create the entire system (and upgrade it as necessary).
(2) The dummy file system typically runs in memory (which is very fast, and usually plenty large for a diff-like 'patch').
(3) It seems like a perfect fit for a unioning file system.

I am actually a fan of transactional file systems, but unionfs seems perfect for this. There is a BSD unionfs it seems here: http://people.freebsd.org/~daichi/unionfs/ [freebsd.org]. Also, if you are in Linux, and you want copy-on-write for some reason, check this out: http://www.am-utils.org/project-unionfs.html [am-utils.org].

Factual Errors

[DaMattster]

Most open source operating systems deliver their patches primarily as source code. I know Free and Net BSD and Linux provide source based patches. In fact, if you track the FreeBSD security announcements and errata information, you download a source code patch in the form of a diff file. To apply the patch, simply make certain you have downloaded the source code in the /usr/src directory and use the patch command. From there, the diffs are applied and you can run make to recompile the patched section. The commercial Linux vendors like Red Hat and SuSE provide binary patches for convenience purposes. The author of this article really should do more homework before making the statement that he did. Personally, I like the patch and compile method. I do know that this is a more secure way of supplying patches because you can read the source code and it makes delivering malware harder. I like to see what is going on behind the scenes.