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
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
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
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,
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
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
