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 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 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 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 Fri, Sep 26, 2014 at 10:51:36AM -0400, Steve Simmons wrote:
> The more I see of how many bash-isms work when bash is invoked as /bin/sh,
> the more convinced I get that we need to either
>
> 1) make bash when invoked as /bin/sh fail those bash-isms
>
> 2) build a 'real' /bin/sh without those
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 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
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 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
21 matches
Mail list logo
