Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKA
On 9/28/14, 4:33 PM, Mark Goldfinch wrote:
> On 29 September 2014 00:42, Christian Weisgerber 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 Op
On 9/28/14, 4:01 AM, Mark Goldfinch wrote:
> Greetings,
>
> On 28 Sep 2014 19:41, "John E. Malmberg" wrote:
>>
>> On 9/27/2014 6:49 PM, Mark Goldfinch wrote:
>>> 1) Remove y.tab.c from the original tarball, and ensure the clean method
>>> within Makefile removes it
>>
>> The VMS build procedure c
On 9/27/14, 10:03 PM, Eric Blake wrote:
>> Yes, it's an application requirement. Regardless, all the versions of bash
>> we're talking about here reject non-identifiers.
>
> I'm still trying to find that line in the actual POSIX spec.
"The function is named fname; the application shall ensure t
On 9/28/14, 12:31 PM, Ángel González wrote:
> There's also the middleground of not parsing the environment variables
> before they are going to be used. That avoids the issues caused by
> parsing what is not needed *and* doesn't break backwards compatibility.
> See the patch I sent a couple days a
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
On 9/28/14, 5:25 AM, Franz Beck wrote:
> Please refer to below Focus Article:
> http://www.focus.de/digital/schlimmer-als-heartbleed-sicherheitsluecke-bedroht-linux-unix-und-mac-os-x_id_4160658.html
Sorry, I'm mono-lingual.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
On 29 September 2014 00:42, Christian Weisgerber 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 beca
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
On 9/28/14, 4:32 AM, TrevD wrote:
> Hi
>
> There a number of issue in restricted mode. What's the best method for
> disclosure.
Restricted mode (set -r) has a number of well-known weaknesses and survives
only as a historical artifact. It's not a serious security mechanism.
Chet
--
``The lyf s
David A. Wheeler wrote:
> 2. Import environment variables *ONLY* when they are requested; do *NOT*
> import them by default. Christos Zoulas has proposed this. This *IS* a real
> backwards-incompatible change. But most users do *NOT* use this
> functionality, and increasingly downstream syste
| 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
Please refer to below Focus Article:
http://www.focus.de/digital/schlimmer-als-heartbleed-sicherheitsluecke-bedroht-linux-unix-und-mac-os-x_id_4160658.html
Thanks for your attention!
Franz
Johannesburg
Hi
There a number of issue in restricted mode. What's the best method for
disclosure.
BASH PATCH REPORT
=
Bash-Release: 4.2
Patch-ID: bash42-049
Bug-Reported-by:Tavis Ormandy
Bug-Reference-ID:
Bug-Reference-URL: http://twitter.com/taviso/statuses/514887394294652929
Bug-Description:
Un
On 9/28/14, 12:51 AM, Deron Meranda wrote:
> I was wondering if anybody was going to address the problem with 4.2 patch
> 49 ?
I've attached a corrected version and I will update the FTP sites today.
> Not only is there a critical line of code missing, but the the 'patch'
> command will also fail
Deron Meranda:
> I was wondering if anybody was going to address the problem with 4.2 patch
> 49 ?
>
> It is still corrupted on the FTP server. There are a few lines that appear
> to have been deleted out of the middle of the patch file.
Indeed.
> Not only is there a critical line of code miss
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
> >
Mark Goldfinch:
> Can someone clarify to me why y.tab.c is included within the bash source
> tree if it is generated from parse.y?
>
> If one looks in the FreeBSD ports tree, they're deliberately taking the
> initiative to touch parse.y to ensure that y.tab.c is always rebuilt.
They also have a
Greetings,
On 28 Sep 2014 19:41, "John E. Malmberg" wrote:
>
> On 9/27/2014 6:49 PM, Mark Goldfinch wrote:
>> 1) Remove y.tab.c from the original tarball, and ensure the clean method
>> within Makefile removes it
>
> The VMS build procedure currently needs the y.tab.c file, as the tools to
build
26 matches
Mail list logo
