Linda Walsh wrote:
> wrote:
> > The change only affects environment variables **loaded as exported
> > functions**. Bash won't forbid you from using / inside the name of an
> > environment variables.
> >
>
> The below doesn't demonstrate bash doing anything with the variable you
> decla
2014-09-27 22:48:44 -0600, Eric Blake:
> On 09/27/2014 08:50 PM, Chet Ramey wrote:
> > BASH PATCH REPORT
> > =
>
> > /* Don't import function names that are invalid identifiers from the
> > environment, though we stil
> I'd send it to your vendor. If appropriate they can send it upstream.
>
>
>
> Chet
I've sent this to a debian person following advice on the Arch list I initially
asked. I probably won't get used as I imagine they'll want a more general
approach to all the various versions of the bash fixe
On 9/28/14, 12:10 PM, becker...@gmail.com wrote:
> On Sunday, September 28, 2014 4:38:24 PM UTC+1, beck...@gmail.com wrote:
> ..
>> If I use the Arch linux [testing] bash-4.3.027-1 which is uses this patch
>> then I have a patch against the at(1) source which converts exported
>> functions i
� wrote:
The change only affects environment variables **loaded as exported
functions**. Bash won't forbid you from using / inside the name of an
environment variables.
The below doesn't demonstrate bash doing anything with the variable you
declared.
Y
On 9/28/14, 11:38 AM, becker...@gmail.com wrote:
> If I use the Arch linux [testing] bash-4.3.027-1 which is uses this patch
> then I have a patch against the at(1) source which converts exported
> functions into something that sh can parse and allows exported functions to
> be used in the envi
On 9/28/14, 12:48 AM, Eric Blake wrote:
> This patch forbids importing function names containing '/' (yay!), and
> we already established that bash has never been able to properly import
> functions with names containing '='. But I'm assuming there will need
> to be a followup patch to actually r
The change only affects environment variables **loaded as exported
functions**. Bash won't forbid you from using / inside the name of an
environment variables.
You can easily confirm with:
> env -i 'foo/bar=baz' bash -c env
Best regards
| correction: variable called "/tmp/exploit=me" => a variable called
"/tmp/exploit" with a value "me"
On Mon, Sep 29, 2014 at 2:26 AM, Jon Seymour wrote:
> To clarify, I am not sure that the presence of a variable called
> "/tmp/exploit=me" represents a huge vuilnerability for at(1) since
> any
To clarify, I am not sure that the presence of a variable called
"/tmp/exploit=me" represents a huge vuilnerability for at(1) since
anyone who can arrange for this to happen can probably mutate the
user's environment in anyway they choose, but I did want to point out
that atrun will attempt to exec
On Sunday, September 28, 2014 4:38:24 PM UTC+1, beck...@gmail.com wrote:
..
> If I use the Arch linux [testing] bash-4.3.027-1 which is uses this patch
> then I have a patch against the at(1) source which converts exported
> functions into something that sh can parse and allows exported func
On Sunday, September 28, 2014 3:50:07 AM UTC+1, Chet Ramey wrote:
> BASH PATCH REPORT
>
..
> --
>
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>
>``Ars longa, vita brevis'' - Hippocrates
>
> Chet Ramey, ITS, CWRUc
If I use the Arch linux [t
Does anyone know if Red Hat intends on remerging with official bash? (This
may be better directed at a seperate thread with them.)
-Nathan
On Sep 28, 2014 12:49 AM, "Eric Blake" wrote:
> On 09/27/2014 08:50 PM, Chet Ramey wrote:
> >BASH PATCH REPORT
> >
On 09/27/2014 08:50 PM, Chet Ramey wrote:
>BASH PATCH REPORT
>=
> /* Don't import function names that are invalid identifiers from the
>environment, though we still allow them to be defined as shell
>
Chet Ramey wrote on Sat, 27 Sep 2014 22:50:07:
> Bash-Release: 4.3
> Patch-ID: bash43-027
> Bug-Reported-by: Florian Weimer
Excellent.
Thanks for pulling in Florian Weimer's prefix/suffix approach. This is a big
help.
--- David A. Wheeler
15 matches
Mail list logo
