On 9/28/14, 4:33 PM, Mark Goldfinch wrote:
> 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
OK. The reason for this is because in bash-4.3, I changed the patch
process to include patches for y.tab.c if parse.y was changed. This is
to reduce -- but not completely eliminate -- the dependency on bison.
Previous versions didn't include changes to y.tab.c in patches to parse.y,
so you can't assume that the y.tab.c in the source tree is up to date, and
patching it would have had unintended side effects. If you're wondering
how this could be, consider an environment that separates source and build
trees (configure makes this very easy). In this case, y.tab.c will be
created in the build tree after parse.y is updated, but the original
y.tab.c in the source tree, while it was valid before the patch, is now out
of date.
> Assuming the files have been edited in the correct order.
It's hard to imagine a situation where parse.y gets patched,
y.tab.c doesn't, and y.tab.c still ends up newer than parse.y. A system
with clock problems that bad probably has bigger problems, too.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
