On 09/29/2014 09:05 AM, Henrique de Moraes Holschuh wrote:
> On Mon, 29 Sep 2014, Paul Eggert wrote:
>> which is caused by a widely-distributed Bash fix that overreacted to
>> the bug and is causing me more problems than the bug did. Let's not
>> do something like this with Autoconf.
>
> Hmm, tha
On 2014-09-29 15:24 +0200, Ralf Corsepius wrote:
> On 09/29/2014 03:13 PM, Eric Blake wrote:
> > The whole point of the Shell Shock bug is that there are some values
> > that you cannot safely export, because doing so risks your child
> > misbehaving. As we cannot predict which child processes wil
On Mon, 29 Sep 2014, Paul Eggert wrote:
> which is caused by a widely-distributed Bash fix that overreacted to
> the bug and is causing me more problems than the bug did. Let's not
> do something like this with Autoconf.
Hmm, that "overreaction" is currently mitigating two undisclosed RCE bugs in
I don't think it's worth modifying Autoconf to warn about this. By the time a
new Autoconf version is released, and used to generate source packages
containing configure scripts that are themselves distributed, and these source
packages are built, he problem will no longer be important.
I'm c
On 09/29/2014 03:13 PM, Eric Blake wrote:
On 09/29/2014 05:19 AM, Ralf Corsepius wrote:
On 09/25/2014 05:53 PM, Eric Blake wrote:
Huh? There is no wasted effort in teaching configure scripts to warn
users that they are running on an unpatched vulnerable system. Just
because a fix may be avail
On 09/29/2014 05:19 AM, Ralf Corsepius wrote:
> On 09/25/2014 05:53 PM, Eric Blake wrote:
>
>> Huh? There is no wasted effort in teaching configure scripts to warn
>> users that they are running on an unpatched vulnerable system. Just
>> because a fix may be available doesn't mean everyone is run
On 09/25/2014 05:53 PM, Eric Blake wrote:
Huh? There is no wasted effort in teaching configure scripts to warn
users that they are running on an unpatched vulnerable system. Just
because a fix may be available doesn't mean everyone is running the fix.
I do not see any sense in this at all, un
On Sep 27, 2014, at 6:51 PM, Eric Blake wrote:
> On 09/27/2014 04:21 PM, Chet Ramey wrote:
>>
>>> 2) build a 'real' /bin/sh without those compiled in. This begs the
>>> definition of 'real', but IMHO if it's not in POSIX, it shouldn't be in
>>> 'real' /bin/sh
>>
>> This is dash's niche.
>
>
On 09/27/2014 04:21 PM, Chet Ramey wrote:
>> 1) make bash when invoked as /bin/sh fail those bash-isms
>
> It's come up before, and it's not something that bash has ever been
> intended to do. When invoked as /bin/sh, bash will behave as a posix
> superset. Posix allows this.
Even dash is a po
On 9/26/14, 10:51 AM, Steve Simmons wrote:
>
> On Sep 26, 2014, at 10:36 AM, Eric Blake wrote:
>
>> . . . I _also_ agree that since function exports are NOT required by POSIX,
>> that it would be okay if we let /bin/bash continue to import functions
>> by default, but have bash invoked as /bin/s
Eric Blake wrote:
What prevents BASH_FUNC_foo = '(){ :; ...';
Nothing, as you wrote it, because you have no () on the left of the
equal.
Then what is wrong with
foo()={ :; ... ;}... That cannot be a legal variable name either.
Other languages like PERL rely on ENV vars and will fail b
On 09/26/2014 02:22 PM, Linda Walsh wrote:
> Eric Blake wrote:
>
>> They are not portable to broken bash. But the argument in these threads
>> is that bash's implementation of function exports should be changed so
>> that _fixed_ bash will once again be POSIX compliant and let this
>> bog-standar
Eric Blake wrote:
They are not portable to broken bash. But the argument in these threads
is that bash's implementation of function exports should be changed so
that _fixed_ bash will once again be POSIX compliant and let this
bog-standard assignment work regardless of contents. If Chet accept
On Fri, Sep 26, 2014 at 10:36 AM, Eric Blake wrote:
> On 09/26/2014 08:22 AM, Zack Weinberg wrote:
>>
>> The question in my mind is, is exporting functions a POSIX shell feature?
>> If not, perhaps it should just be scrapped altogether.
>
> Why not read POSIX and find out for yourself?
I would no
On Fri, 2014-09-26 at 10:51 -0400, Steve Simmons wrote:
> 2) build a 'real' /bin/sh without those compiled in. This begs the
> definition of 'real', but IMHO if it's not in POSIX, it shouldn't be
> in 'real' /bin/sh
Ubuntu and it's derivatives have been doing this since 2006. /bin/sh on
these sys
On 2014-09-25 19:14 -0400, Shawn H Corey wrote:
> On Thu, 25 Sep 2014 09:53:14 -0600
> Eric Blake wrote:
> > Huh? There is no wasted effort in teaching configure scripts to warn
> > users that they are running on an unpatched vulnerable system. Just
> > because a fix may be available doesn't mean
On 2014-09-25 15:08 -0700, Linda Walsh wrote:
> Eric Blake wrote:
> > Where I'm coming from is that in portable shell programming, you _can't_
> > assign a value to f()=... The fact that portable programs are now
> > slammed with the notion that some values cannot be portably assigned
> > to a var
On 2014-09-26 08:51 -0600, Eric Blake wrote:
> On 09/26/2014 08:45 AM, Nick Bowler wrote:
> > On 2014-09-25 15:08 -0700, Linda Walsh wrote:
> >> Eric Blake wrote:
> >>> Where I'm coming from is that in portable shell programming, you _can't_
> >>> assign a value to f()=... The fact that portable p
On Sep 26, 2014, at 10:36 AM, Eric Blake wrote:
> . . . I _also_ agree that since function exports are NOT required by POSIX,
> that it would be okay if we let /bin/bash continue to import functions
> by default, but have bash invoked as /bin/sh refuse to do imports by
> default. . .
The more I
On 09/26/2014 08:45 AM, Nick Bowler wrote:
> On 2014-09-25 15:08 -0700, Linda Walsh wrote:
>> Eric Blake wrote:
>>> Where I'm coming from is that in portable shell programming, you _can't_
>>> assign a value to f()=... The fact that portable programs are now
>>> slammed with the notion that some v
On 09/26/2014 08:22 AM, Zack Weinberg wrote:
> On September 26, 2014 3:53:53 AM EDT, lolilolicon
> wrote:
>> On Fri, Sep 26, 2014 at 6:08 AM, Linda Walsh wrote:
>
>>> This behavior has been around for 20+ without it being judged "so
>> bad",
>>
>> I don't think that's a sufficient argument for
On September 26, 2014 3:53:53 AM EDT, lolilolicon wrote:
>On Fri, Sep 26, 2014 at 6:08 AM, Linda Walsh wrote:
>> This behavior has been around for 20+ without it being judged "so
>bad",
>
>I don't think that's a sufficient argument for "this is not so bad".
>
>First, the fact that the bug has ex
On Fri, Sep 26, 2014 at 6:08 AM, Linda Walsh wrote:
>
>
> Eric Blake wrote:
>>
>> Where I'm coming from is that in portable shell programming, you _can't_
>> assign a value to f()=... The fact that portable
>> programs are now "slammed"[sic] with the notion that some values cannot be
>> portably
Eric Blake writes:
> Overkill. The security hole arises because the problem, as it currently
> exists, is triggerable by ANY portable environment variable definition.
In the context of security you need to forget about portable. You need
to think about the improbable.
Andreas.
--
Andreas Sc
Eric Blake wrote:
Where I'm coming from is that in portable shell programming, you _can't_
assign a value to f()=... The fact that portable
programs are now "slammed"[sic] with the notion that some values cannot be
portably assigned to a variable...
---
slammed? It's not like this is new...
On Thu, 25 Sep 2014 09:53:14 -0600
Eric Blake wrote:
> On 09/25/2014 09:45 AM, Shawn H Corey wrote:
> > On Thu, 25 Sep 2014 08:55:45 -0600
> > Eric Blake wrote:
> >
> >> On 09/25/2014 07:51 AM, Bob Friesenhahn wrote:
> >>> It may be that some users of 'autoconf' will be at risk due to the
> >>>
Eric Blake wrote:
And _that's_ what I want changed, by proposing that bash use 'f()=...'
rather than 'f=() {...' as the magic it uses for exporting functions
from parent to child.
---
That could still be put in the environment (though not as easily w/o
special code).
Not that it is any mor
On 09/25/2014 01:15 PM, Linda Walsh wrote:
> Eric Blake wrote:
>> And _that's_ what I want changed, by proposing that bash use 'f()=...'
>> rather than 'f=() {...' as the magic it uses for exporting functions
>> from parent to child.
>>
> ---
> That could still be put in the environment (though
On 09/25/2014 11:21 AM, Nick Bowler wrote:
> On 2014-09-25 08:55 -0600, Eric Blake wrote:
>> On 09/25/2014 07:51 AM, Bob Friesenhahn wrote:
>>> It may be that some users of 'autoconf' will be at risk due to the dire
>>> bash security bug described at
>>> "http://www.theregister.co.uk/2014/09/24/bas
On 2014-09-25 08:55 -0600, Eric Blake wrote:
> On 09/25/2014 07:51 AM, Bob Friesenhahn wrote:
> > It may be that some users of 'autoconf' will be at risk due to the dire
> > bash security bug described at
> > "http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/";.
> >
> > Take care that the e
On Thu, 25 Sep 2014, Eric Blake wrote:
On 09/25/2014 07:51 AM, Bob Friesenhahn wrote:
It may be that some users of 'autoconf' will be at risk due to the dire
bash security bug described at
"http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/";.
Take care that the environment is carefully
On 09/25/2014 09:45 AM, Shawn H Corey wrote:
> On Thu, 25 Sep 2014 08:55:45 -0600
> Eric Blake wrote:
>
>> On 09/25/2014 07:51 AM, Bob Friesenhahn wrote:
>>> It may be that some users of 'autoconf' will be at risk due to the
>>> dire bash security bug described at
>>> "http://www.theregister.co.u
On Thu, 25 Sep 2014 08:55:45 -0600
Eric Blake wrote:
> On 09/25/2014 07:51 AM, Bob Friesenhahn wrote:
> > It may be that some users of 'autoconf' will be at risk due to the
> > dire bash security bug described at
> > "http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/";.
> >
> > Take care
On 09/25/2014 08:55 AM, Eric Blake wrote:
> On 09/25/2014 07:51 AM, Bob Friesenhahn wrote:
>> It may be that some users of 'autoconf' will be at risk due to the dire
>> bash security bug described at
>> "http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/";.
>>
>> Take care that the environmen
On 09/25/2014 07:51 AM, Bob Friesenhahn wrote:
> It may be that some users of 'autoconf' will be at risk due to the dire
> bash security bug described at
> "http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/";.
>
> Take care that the environment is carefully vetted.
There's nothing that ./c
35 matches
Mail list logo
