On 10/16/2014 03:02 PM, Dave Kalaluhi wrote:
> We have been compiling some of the older versions of bash to fix
> vulnerabilities, and for the most, has been working.
>
> However, when we patch the 013 patch for CVE-2014-7187, and run the
> nested loop, it's still showing as vulnerable.
Exactly H
On 10/16/14, 5:02 PM, Dave Kalaluhi wrote:
> We have been compiling some of the older versions of bash to fix
> vulnerabilities, and for the most, has been working.
>
> However, when we patch the 013 patch for CVE-2014-7187, and run the
> nested loop, it's still showing as vulnerable.
>
> Has any
We have been compiling some of the older versions of bash to fix
vulnerabilities, and for the most, has been working.
However, when we patch the 013 patch for CVE-2014-7187, and run the
nested loop, it's still showing as vulnerable.
Has anyone else had a similiar experience?
Thanks for the help,
2014-10-16 15:09 GMT+02:00 Chet Ramey :
> On 10/15/14, 1:49 PM, lorenz.bucher@rohde-schwarz.com wrote:
>
> > But anyway.
> > In my opinion I should trust a shell not violating their own rules and be
> > able to import their own variables.
>
> That's not the issue. The shell can import variabl
On 10/15/14, 1:49 PM, lorenz.bucher@rohde-schwarz.com wrote:
> But anyway.
> In my opinion I should trust a shell not violating their own rules and be
> able to import their own variables.
That's not the issue. The shell can import variables like that just fine,
as evidenced by exported fun
On 10/15/14, 9:38 AM, lorenz.bucher@rohde-schwarz.com wrote:
> Hello,
> in refer to
> http://lists.gnu.org/archive/html/bug-bash/2014-09/msg00278.html variables
> with suffix "%%" can't be set/exported.
> This makes problems restoring environments which where saved by external
> programs lik
