1. n. A temporary addition to a piece of code, usually as a quick-and-dirty remedy to an existing bug or misfeature. A patch may or may not work, and may or may not eventually be incorporated permanently into the program. Distinguished from a diff or mod by the fact that a patch is generated by more primitive means than the rest of the program; the classical examples are instructions modified by using the front panel switches, and changes made directly to the binary executable of a program originally written in an HLL. Compare one-line fix.
2. vt. To insert a patch into a piece of code.
3. [in the Unix world] n. A diff (sense 2).
4. A set of modifications to binaries to be applied by a patching program. IBM operating systems often receive updates to the operating system in the form of absolute hexadecimal patches. If you have modified your OS, you have to disassemble these back to the source. The patches might later be corrected by other patches on top of them (patches were said to “grow scar tissue”). The result was often a convoluted patch space and headaches galore.
5. [Unix] the patch(1) program, written by Larry Wall, which automatically applies a patch (sense 3) to a set of source code.
There is a classic story of a tiger team penetrating a secure military computer that illustrates the danger inherent in binary patches (or, indeed, any patches that you can't — or don't — inspect and examine before installing). They couldn't find any trap doors or any way to penetrate security of IBM's OS, so they made a site visit to an IBM office (remember, these were official military types who were purportedly on official business), swiped some IBM stationery, and created a fake patch. The patch was actually the trapdoor they needed. The patch was distributed at about the right time for an IBM patch, had official stationery and all accompanying documentation, and was dutifully installed. The installation manager very shortly thereafter learned something about proper procedures.