Re: y.tab.c inclusion within the source tree

[Mark Goldfinch]

On 29 September 2014 00:42, Christian Weisgerber <naddy@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.