On 29 September 2014 00:42, Christian Weisgerber <na...@mips.inka.de> wrote:
> They also have a dependency on the bison port, because parse.y does > not build correctly with FreeBSD's yacc(1). You end up with a bash > that has broken $(...) parsing. Same issue on OpenBSD, where the > port doesn't touch parse.y because there is no need to. > For these platforms, if anyone is using the patches directly from the GNU repository, if they're *not* running 4.3 they could well be still vulnerable if they're reliant upon the supplied y.tab.c: bash205b-009: y.tab.c unpatched bash30-018: y.tab.c unpatched bash31-019: y.tab.c unpatched bash40-040: y.tab.c unpatched bash41-013: y.tab.c unpatched bash42-049: y.tab.c unpatched bash43-026: y.tab.c patched Granted the subsequent patch should take care of things too. > a patch which (correctly) only patches parse.y, > > ... will cause parse.y to have a newer timestamp. > Assuming the files have been edited in the correct order. While I understand the reasons for including a generated copy, this only add yet another maintenance burden - surely for platforms where the required bison is available, the build-chain should take steps to ensure y.tab.c is actually generated. For everyone else surely it should be their responsibility to have the required tools available at build time? Thanks, Mark.
