On Eric Blake wrote:
> On 09/28/2014 10:31 AM, Ángel González wrote:
> > 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. Bu
Chet Ramey wrote:
> 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 th
On 09/28/2014 10:31 AM, Ángel González wrote:
> 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
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
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
On Saturday, September 27, 2014 3:51:23 PM UTC+1, Andreas Schwab wrote:
> becker...@gmail.com writes:
>
>
>
> > $ (env;echo echo 'hello') | bash
>
>
>
> You cannot expect that the output of env is parsable by a shell. First
>
> and foremost, it lacks any kind of quoting.
env may not be th
On 9/27/14, 8:06 AM, David A. Wheeler wrote:
> I agree it would be MUCH better to append () to the "variable" name if it is
> a function export. If that suffix can be included in the official bash
> release, I would be delighted.
>
> There had been earlier claims that () might fail on old syste
becker...@gmail.com writes:
> $ (env;echo echo 'hello') | bash
You cannot expect that the output of env is parsable by a shell. First
and foremost, it lacks any kind of quoting.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 82
On Sep 27, 2014, at 2:19 AM, Eric Blake wrote:
> The prefix is nice for quick identification, but what is ESSENTIAL is
> something that puts shell functions in a namespace that is untouchable
> by normal shell variables (the "()" suffix in Florian's patch). If all
> you do is add a prefix, but
I currently have this problem with the latest bash from Arch linux which is
biting my at(1) commands. Exported functions make the environment
non-parseable.
##
robin@bunyip:~
$ export -nf psg hsg #clean out my exported functions
robin
I agree it would be MUCH better to append () to the "variable" name if it is a
function export. If that suffix can be included in the official bash release,
I would be delighted.
There had been earlier claims that () might fail on old systems, but I have not
seen evidence of it. I do not have
On Saturday, September 27, 2014 8:19:49 AM UTC+2, Eric Blake wrote:
>
> I am also in favor of both approaches - moving shell functions into a
> non-colliding namespace (so that arbitrary contents of regular variables
> CANNOT trigger parser bugs) and making shell function exports
> configurable an
On 09/26/2014 03:47 PM, David A. Wheeler wrote:
> I appreciate the effort made in patch bash43-026, but this patch doesn't even
> BEGIN to solve the underlying shellshock problem. This patch just continues
> the "whack-a-mole" job of fixing parsing errors that began with the first
> patch. Bas
I appreciate the effort made in patch bash43-026, but this patch doesn't even
BEGIN to solve the underlying shellshock problem. This patch just continues
the "whack-a-mole" job of fixing parsing errors that began with the first
patch. Bash's parser is certain have many many many other vulnerab
In article ,
lolilolicon wrote:
> I think almost as severe as CVE-2014-6271 is that it's still possible to
> mask commands in a bash script by changing it's environment.
> For example, true='() { false;}' or grep='() { /bin/id;}' ...
Yes, and BTW, I don't think this is POSIX compliant:
8.1
On Fri, Sep 26, 2014 at 3:24 PM, Vincent Lefevre wrote:
> On 2014-09-25 03:54:19 +0800, lolilolicon wrote:
>> [...] that it's still possible to
>> mask commands in a bash script by changing it's environment.
>>
>> For example, true='() { false;}' or grep='() { /bin/id;}' ...
>
> Yes, and BTW, I do
On 2014-09-25 03:54:19 +0800, lolilolicon wrote:
> I think almost as severe as CVE-2014-6271 is that it's still possible to
> mask commands in a bash script by changing it's environment.
>
> For example, true='() { false;}' or grep='() { /bin/id;}' ...
Yes, and BTW, I don't think this is POSIX co
Chet Ramey wrote:
> On 9/25/14, 2:47 PM, lolilolicon wrote:
> > On Fri, Sep 26, 2014 at 2:28 AM, Ángel González wrote:
> > [...]
> >> On the other hand, this approach would be much more interesting if bash
> >> delayed parsing of exported functions until they are used (ie. check
> >
> > This is wh
> Not quite. While autoloaded functions are lazily evaluated, you have to
> pay the price of searching $FPATH and loading them in every shell, and
> there still has to be a mechanism to indicate which functions should be
> autoloaded in each shell.
How about lazy loading functions using the follow
> It's not backwards compatible, but who cares? The only time it
> matters is if you are mixing old and new bash ON THE SAME SYSTEM,
> and TRYING TO EXPORT FUNCTIONS BETWEEN THEM.
It might happen during the update of bash. A bash process exec()ed
before the update would fail to export a function
> I'd much rather prefer the use of an invalid shell name (such as
> f()=...) than a valid shell name (BASH_FUNCTION_foo=()...).
Using a BASH_ prefix has some advantages:
* Anyone setting such a variable, might expect it could change the
behaviour of bash. Any script allowing setting untruste
On Fri, Sep 26, 2014 at 2:53 AM, Linda Walsh wrote:
> ---
> "prevert" _might_ have been more obviously seen as applicable to a bash
> programmer who is "pre-bent" or "pre-twisted" from having programmed in
> shell for so long, compared to the nick, lilololicon, with its 'H'y (as in
> 'Hentai'-y)
On 9/25/14, 2:47 PM, lolilolicon wrote:
> On Fri, Sep 26, 2014 at 2:28 AM, Ángel González wrote:
> [...]
>> On the other hand, this approach would be much more interesting if bash
>> delayed parsing of exported functions until they are used (ie. check
>
> This is what function autoload is for in
On Sep 25, 2014, at 2:47 PM, lolilolicon wrote:
> On Fri, Sep 26, 2014 at 2:28 AM, Ángel González wrote:
> [...]
>> On the other hand, this approach would be much more interesting if bash
>> delayed parsing of exported functions until they are used (ie. check
>
> This is what function autoload
lolilolicon wrote:
On Thu, Sep 25, 2014 at 9:00 PM, Chet Ramey wrote:
> Even if you use it as a rhetorical device, it distracts from (and
> detracts from) your argument. It doesn't improve the quality of the
> discussion, so it's best not to use it.
Agreed. People can take light-hearted side
On Fri, Sep 26, 2014 at 2:28 AM, Ángel González wrote:
[...]
> On the other hand, this approach would be much more interesting if bash
> delayed parsing of exported functions until they are used (ie. check
This is what function autoload is for in zsh. It's indeed a better
approach. It was also su
Steve Simmons wrote:
> ..bash_once defines SET_ONCE and loads literally hundreds of environment
> variables and exports many shell functions that would otherwise have to be
> defined in .bashrc and processed on every freaking run. .bash_once is about
> 50 times larger than .bashrc and .bash_logi
On 09/25/2014 07:03 AM, Chet Ramey wrote:
> On 9/25/14, 4:52 AM, Gabriel Corona wrote:
>> Hello,
>>
>> As the interface is not specified, would it make sense to:
>>
>> * add a prefix (use BASH_FUNCTION_foo instead of foo for exported
>>function foo);
I'd much rather prefer the use of an inval
On Thursday, September 25, 2014 10:29:16 AM Chet Ramey wrote:
> On 9/25/14, 10:25 AM, Dan Douglas wrote:
>
> > Have you considered the FPATH mechanism? Exploiting it requires being able
to
> > create files and set FPATH accordingly. I've had some success with the
> > function loader code in exa
On 9/25/14, 10:25 AM, Dan Douglas wrote:
> Have you considered the FPATH mechanism? Exploiting it requires being able to
> create files and set FPATH accordingly. I've had some success with the
> function loader code in examples/functions/autoload.*. I believe it serves
> mostly the same purpos
On Thursday, September 25, 2014 09:03:03 AM Chet Ramey wrote:
> On 9/25/14, 4:52 AM, Gabriel Corona wrote:
> > Hello,
> >
> > As the interface is not specified, would it make sense to:
> >
> > * add a prefix (use BASH_FUNCTION_foo instead of foo for exported
> >function foo);
> >
> > * sti
On Thu, Sep 25, 2014 at 9:00 PM, Chet Ramey wrote:
> Even if you use it as a rhetorical device, it distracts from (and detracts
> from) your argument. It doesn't improve the quality of the discussion, so
> it's best not to use it.
Agreed. People can take light-hearted side remarks too seriously.
On 9/25/14, 4:52 AM, Gabriel Corona wrote:
> Hello,
>
> As the interface is not specified, would it make sense to:
>
> * add a prefix (use BASH_FUNCTION_foo instead of foo for exported
>function foo);
>
> * still expand the variable if it matches the 'exported function'
>pattern.
Yes,
On 9/25/14, 6:12 AM, lolilolicon wrote:
> On Thu, Sep 25, 2014 at 6:09 PM, Pierre Gaston
> wrote:
>>> In any event, this is but irrelevant to the discussion. Do not seize the
>>> red herring.
>>
>>
>> It is fully relevant when you use a sexist stereotype as an argument.
>
> No, I didn't use a se
On 9/25/14, 4:43 AM, Davide Brini wrote:
>> Function export is documented. The exact mechanism need not be.
>
> I'm not arguing about anything, I just have a question. I understand that
> with the current method used to export functions, it is not possible to
> export a variable to a child whose
Hello,
As the interface is not specified, would it make sense to:
* add a prefix (use BASH_FUNCTION_foo instead of foo for exported
function foo);
* still expand the variable if it matches the 'exported function'
pattern.
The first point would reduce the probability of a clash with
a us
Hello,
As the interface is not specified, would it make sense to:
* add a prefix (use BASH_FUNCTION_foo instead of foo for exported
function foo);
* still expand the variable if it matches the 'exported function'
pattern.
The first point would reduce the probability of a clash with
a us
On Thu, Sep 25, 2014 at 6:09 PM, Pierre Gaston wrote:
>> In any event, this is but irrelevant to the discussion. Do not seize the
>> red herring.
>
>
> It is fully relevant when you use a sexist stereotype as an argument.
No, I didn't use a sexist stereotype "as an argument". Remove that
sentence
On Thu, Sep 25, 2014 at 1:04 PM, lolilolicon wrote:
> On Thu, Sep 25, 2014 at 5:51 PM, Pierre Gaston
> wrote:
> >
> >
> > On Thu, Sep 25, 2014 at 12:42 PM, lolilolicon
> wrote:
> >>
> >> On Thu, Sep 25, 2014 at 7:19 AM, Linda Walsh wrote:
> >> > lolilolicon wrote:
> >> >>
> >> >> I don't expec
On Thu, Sep 25, 2014 at 5:51 PM, Pierre Gaston wrote:
>
>
> On Thu, Sep 25, 2014 at 12:42 PM, lolilolicon wrote:
>>
>> On Thu, Sep 25, 2014 at 7:19 AM, Linda Walsh wrote:
>> > lolilolicon wrote:
>> >>
>> >> I don't expect more than a dozen who rely on this... but bash
>> >> programmers can be qu
On Thu, Sep 25, 2014 at 12:42 PM, lolilolicon wrote:
> On Thu, Sep 25, 2014 at 7:19 AM, Linda Walsh wrote:
> > lolilolicon wrote:
> >>
> >> I don't expect more than a dozen who rely on this... but bash
> >> programmers can be quite the perverts, so...
> >>
> >
> > Personally I find those who don
On Thu, Sep 25, 2014 at 7:19 AM, Linda Walsh wrote:
> lolilolicon wrote:
>>
>> I don't expect more than a dozen who rely on this... but bash
>> programmers can be quite the perverts, so...
>>
>
> Personally I find those who don't read the man page, and then claim that
> documented
> behavior is a
2014-09-25 10:43 GMT+02:00 Davide Brini :
> I'm not arguing about anything, I just have a question. I understand that
> with the current method used to export functions, it is not possible to
> export a variable to a child whose value begins exactly with the characters
> in question. A quick test
On Thu, Sep 25, 2014 at 11:06 AM, lolilolicon wrote:
> On Thu, Sep 25, 2014 at 9:35 AM, Chet Ramey wrote:
> > On 9/24/14, 3:44 PM, lolilolicon wrote:
> >
> >> Personally, I have never needed this feature. I would vote for its
> >> removal: It's very surprising, creates bugs, and is not very usef
On Wed, 24 Sep 2014 21:35:19 -0400, Chet Ramey wrote:
> On 9/24/14, 3:44 PM, lolilolicon wrote:
>
> > Personally, I have never needed this feature. I would vote for its
> > removal: It's very surprising, creates bugs, and is not very useful.
>
> There are more things in heaven and earth that ar
On Thu, Sep 25, 2014 at 9:35 AM, Chet Ramey wrote:
> On 9/24/14, 3:44 PM, lolilolicon wrote:
>
>> Personally, I have never needed this feature. I would vote for its
>> removal: It's very surprising, creates bugs, and is not very useful.
>
> There are more things in heaven and earth that are dreamt
2014-09-25 6:23 GMT+02:00 Linda Walsh :
>
> Maybe exporting fun?
>
> export fun='() { :;}'
>> bash -c 'declare -pf fun'
>>
> bash: line 0: declare: fun: not found
> ...
> I've never seen functions created with an assignment. Is this a
> new syntax in 4.3?
>
> (still in 4.2.43 here)...
Bash ha
lolilolicon wrote:
Obviously, the newly disclosed CVE-2014-6271 is pretty bad.
It's been patched now, but I think it's worthwhile to further discuss
how exported functions are implemented in bash.
I'm no bash expert: before today I didn't even realize bash functions
can be exported. And I certa
On 9/24/14, 3:44 PM, lolilolicon wrote:
> Personally, I have never needed this feature. I would vote for its
> removal: It's very surprising, creates bugs, and is not very useful.
There are more things in heaven and earth that are dreamt of in your
philosophy.
> Otherwise, if this feature is goi
On Sep 24, 2014, at 4:06 PM, lolilolicon wrote:
> On Thu, Sep 25, 2014 at 3:53 AM, Greg Wooledge wrote:
>>
>> So, if Chet removes the feature, it would probably break something that
>> someone cares about. Maybe there could be a compile-time option to
>> disable it. Maybe there already is --
lolilolicon wrote:
I don't expect more than a dozen who rely on this... but bash
programmers can be quite the perverts, so...
Personally I find those who don't read the man page, and then claim that
documented
behavior is a "bug" are the real "perverts". They expect documented
behavior to w
On 9/24/14, 4:07 PM, Greg Wooledge wrote:
> On Thu, Sep 25, 2014 at 03:54:19AM +0800, lolilolicon wrote:
>> I think almost as severe as CVE-2014-6271 is that it's still possible to
>> mask commands in a bash script by changing it's environment.
>>
>> For example, true='() { false;}' or grep='() { /
On Thu, Sep 25, 2014 at 03:54:19AM +0800, lolilolicon wrote:
> I think almost as severe as CVE-2014-6271 is that it's still possible to
> mask commands in a bash script by changing it's environment.
>
> For example, true='() { false;}' or grep='() { /bin/id;}' ...
I'm still waiting for someone to
On Thu, Sep 25, 2014 at 3:53 AM, Greg Wooledge wrote:
> On Thu, Sep 25, 2014 at 03:44:23AM +0800, lolilolicon wrote:
>> Otherwise, if this feature is going to stay (can anyone enlighten me why
>> it's useful?), please document it explicitly.
>
> First, it is documented:
>
> Functions may be
I think almost as severe as CVE-2014-6271 is that it's still possible to
mask commands in a bash script by changing it's environment.
For example, true='() { false;}' or grep='() { /bin/id;}' ...
On Thu, Sep 25, 2014 at 03:44:23AM +0800, lolilolicon wrote:
> Otherwise, if this feature is going to stay (can anyone enlighten me why
> it's useful?), please document it explicitly.
First, it is documented:
Functions may be exported so that subshells automatically have them
defined
Obviously, the newly disclosed CVE-2014-6271 is pretty bad.
It's been patched now, but I think it's worthwhile to further discuss
how exported functions are implemented in bash.
I'm no bash expert: before today I didn't even realize bash functions
can be exported. And I certainly wouldn't expect
57 matches
Mail list logo
