Slashdot Mirror
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."
The OS for people with unlimited spare time.
PF is very good and much better then pos netfilter.
PFSense has to be the best firewall software around. PFSense > mOnOwall, smoothwall, or any pos Linux firewall
BLOB means something different to OpenBSD people.. as does "vulnerability".
How we know is more important than what we know.
fact: You don't know what binary blobs are.
You obviously don't understand what a binary blob is; let me direct you to the wikipedia page so you can educate yourself:
http://en.wikipedia.org/wiki/Binary_blobs
Hint: The article is not about blobs at all.
Linux patches are also distributed as source code. Indeed, isn't this the old skool *nix way, full stop?
it is not suitable for systems that don't have the OpenBSD compiler set installed for whatever reason, such as disk-space constraints
Jesus Christ. If you don't have 2 GB of disk space, and can't afford 2 GB of disk space, maybe you shouldn't run a computer.
Those of you running openbsd from flash media are entitled to flame me, but even then, 2 GB of flash is pretty cheap these days.
The submitter is just pumping up clicks to his own site. You'll notice that he's also the author of TFA. I don't see that this is a particularly useful system, since you'd just be building binaries on another box anyway. If you're going to do that, you might as well just build an upgrade CD and upgrade through the normal process.
"Please describe the scientific nature of the 'whammy'" - Agent Scully
I still use version 2.3, I refuse to run an OS that has a blowfish as its mascot.
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:
/var).
/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) Create a new directory (the author creates something in
(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
(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/. 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.
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.
i'd mod down if i had any points
This is a lot like existing techniques, such as Gentoo's installation sandbox: first, a package is installed in a temporary file system, and changes made during the installation are then merged into the live filesystem (if installation was succesful, and none of the newly added files conflict with files already installed).
Furthermore, the FreeBSD manual recommends a similar procedure for automated building of package lists (lists of files installed by a package): create a regular port, install it into a temporary copy of a base filesystem, and use mtree to figure out what files were modified during the installation process. In this case no chroot environment is used, since ports are expected to honour the installation prefix (given in PREFIX).
So it's a pretty well-established technique; I'm not even sure using it to upgrade the base system is novel: as of late, FreeBSD provides binary updates to its operating system in addition to the traditional source upgrades (and binary releases), although I'm not sure how these packages are created.
Done. Also, I want my innocence back.
Asmandeus
This sounds like a total hassle. What's wrong with proper package management? (I'm not trying to troll, I'd really like to know!)
It's really a shame they couldn't be bothered to program it right the first time.
This is the beauty of peer review, especially from a group as vicious as Slashdot. I imagine the author of this process was so pleased with himself and excited to share his ingenuity with the world, only to submit it here and have his ideas stomped, blasted, toasted, dragged through mud, and rendered to pieces. Not that I would suggest we do anything different, but sometimes I cannot help but to admire the crucible that is public forum.
Why bother.
I agree. PF is just like so totally awesome and everything else is like major sucks. Because I say so.
Why bother.
So start tieing your shoez cuz I'm bieing the drinks.
And OpenBSD is made by frieing some chinks. Word!
I currently use Debian on my desktop; I used to use FreeBSD. Given that both of these are aimed at being general purpose operating systems, whereas OpenBSD is at least perceived as being primarily a firewall/server operating system, why would you choose to use OpenBSD on your desktop instead of something more general purpose? What advantages and limitations does it have over GNU/Linux distributions or FreeBSD as a desktop? Is it something along the lines of you know it from your firewall so you'll use it on your desktop, or do you feel it's independently the best OS for the job?
(I use Debian GNU/Linux largely for hardware support; at least at the time I installed it, no BSD supported my PPC64. That's probably changed, but if it ain't broke, don't fix it eh?)
Look out!
From OpenBSD 101: http://www.openbsd101.com/patching.html
FWIW I've written the following article on how to testdrive (NetBSD, but that shouldn't matter) -current on a 'release' system quite some time ago:
t ml
http://www.feyrer.de/NetBSD/testdriving-current.h
Maybe it's of interest to someone. Enjoy!
- Hubert
Gerardo Santana worked on a project implementing binary patches for OpenBSD at least since 2001. His code is quite reliable, IIRC he basically lacked the needed machines to create the patches for all the OBSD officially supported architectures.