A 35-year-old bug in patch found in efforts to restore 29 year old 2.11BSD:
Larry Wall posted patch 1.3 to mod.sources on May 8, 1985. A number of versions followed over the years. It's been a faithful alley [sic] for a long, long time. I've never had a problem with patch until I embarked on the 2.11BSD restoration project. In going over the logs very carefully, I've discovered a bug that bites this effort twice. It's quite interesting to use 27 year old patches to find this bug while restoring a 29 year old OS...
After some careful research, this turned out to be a fairly obscure bug in an odd edge case caused by "the state of email in the 1980s." which can be relegated to the dustbin of history...
This discussion has been archived.
No new comments can be posted.
A 35-Year-Old Bug in Patch Found in Efforts to Restore 29 Year Old 2.11BSD
|
Log In/Create an Account
| Top
| 5 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
(1)
(Score: 1, Interesting) by Anonymous Coward on Friday August 21 2020, @07:01AM (4 children)
The same bug affected -R patches for PennMUSH, which had a period during the Pern/Penn transition where the file servers got corrupted or lost and certain patchsets/tarballs corrupted. End result, there are around 5 versions unavailable for people attempting to port code forward or backward on the codebase (a reasonably common occurance back in those days when the language was more limited than it was today.)
This bug has been discovered and forgotten multiple times over the years, just like the bash bug that allowed that stack compromise or whatever it was a few years back (I had a friend warning me about it back in the early 1990s in middle school! It was his reason to use csh, ksh, or zsh instead, but since all the Linux distros standardized on bash, including the always important loki installers of the later era, I sucked it up and just used that instead.)
That said: casually removing the feature rather than putting it behind an option switch seems short sighted to me. Sooner or later the LACK of the feature will cause just as much frustration and the next lazy fucker will add it back in without creating an optional switch for it.
(Score: 2) by FatPhil on Friday August 21 2020, @07:25AM (3 children)
"So why '4' in the second 'if' in the quoted code above? what's so magic about it? Indeed, if we hack the patch to have 6 lines of context instead of 3, it applies correctly."
Had that code said:
/* Sometimes we're missing blank lines at the end of patches, magic them back. */
#define MISSING_LINES_FIXUP 4
...
if(p_max - p_end < MISSING_LINES_FIXUP) {
...
(With a better comment and a better name for the macro) then that would be a honking great warning sign that this might be where the dragons are.
I do think this is progress, the prior fixup was a kludge. However, you're also right, it's asking for the same hackish non-solution to be recreated at a future point in time. The ultimate fix is to programatically detect which of the two behaviours is most likely to be required, and - akin to the fuzzing messages - at least warn when an assumption has been programatically made, so that you can know that the program attempted to Do The Right Thing(tm) in the face of ambiguity.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by Mojibake Tengu on Friday August 21 2020, @02:16PM (2 children)
If patch/diff was designed with some initial sanity on mind (technically, it is a strict imperative command language), it would use separate checksum for every command issued at least.
Instead, while email/news did not guarantee a fixed transfer of text files, Unix freaks imposed a space hell on themselves, including tabs hell in makefiles.
A magic number like this is a shameless shame.
Rust programming language offends both my Intelligence and my Spirit.
(Score: 2) by FatPhil on Friday August 21 2020, @03:42PM (1 child)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by leon_the_cat on Saturday August 22 2020, @01:24PM
I know you did that on purpose but I will send you a patch for your comment anyway.