I upgraded from LFS 6.6 to LFS 6.7, and the need for fuzz factor went away. (They rebased the patches.) But now there's this:
Submitted By: Bruce Dubbs <bdubbs_at_linuxfromscratch_dot_org> Date: 2010-05-02 Initial Package Version: 1.22 Upstream Status: Submitted Origin: http://wiki.linuxfromscratch.org/lfs/ticket/2651 Description: Fixes a buffer overflow when creating archives when built by gcc-4.5 diff -urNp tar-1.22-orig/src/create.c tar-1.22/src/create.c --- tar-1.22-orig/src/create.c 2009-07-09 18:38:37.000000000 +0200 +++ tar-1.22/src/create.c 2009-07-09 18:43:44.000000000 +0200 @@ -578,7 +578,10 @@ write_gnu_long_link (struct tar_stat_inf The "date" field after filenames is optional, it doesn't have to be there, but if it _is_ there, it's supposed to start with a tab. And, as with makefiles, it _cares_ that it's a tab character, not spaces. But in this file, between "create.c" and 2009, there are spaces, not tabs. And the current gnu-gnu-gnu-dammit project's version of diff is accepting it. Sigh. mkdir temp temp2 echo hello > temp/"one two" echo walrus > temp2/"one two" diff -ru temp temp2 No special escaping of three consecutive space characters. Note that the date specification itself has spaces in it. So it's not just a question of grabbing the last whitespace-delimited blob... (How do they handle a file that _ends_ with a space character?) I suppose I can start at the end of the line and stop at the first run of more than one space character. Assuming having just _one_ space between the name and the date isn't allowed... HA! The gnu version of patch can't apply the diff the above snippet creates! It tries to patch the file "one". It doesn't support spaces in filenames! They were so clever with their heuristics they broke the thing. (Gee, where have I heard _that_ before...) Right, _my_ heuristic approach to handling this would be to start at the end of the line, work backwards to the last whitespace character occurring before a digit immediately followed by a dash (dash before digit happens in timezone, but digit before dash only happens in the initial date string), and if you hit anything other than a digit, minus, period, or colon, there was no date string, only Zuul. But the question is whether it's worth doing this, since a whitespace damaged patch is a BAD THING and you generally want to KNOW about it... Grr. Figuring out how to implement some specific behavior is easy. Figuring out what these commands should _do_ is hard. Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
