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
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
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 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 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 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 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 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 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: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
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 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
13 matches
Mail list logo
