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
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 the patch I
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. But most
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 systems
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 ago.
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
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. Bash's
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 and
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
On Sep 27, 2014, at 2:19 AM, Eric Blake ebl...@redhat.com 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
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
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 the issue,
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
In article camtvo_osyn6g0d1vnbw1ohpr8w9wg80cpoaegfbkybudzkg...@mail.gmail.com,
lolilolicon loliloli...@gmail.com 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
2014-09-25 6:23 GMT+02:00 Linda Walsh b...@tlinx.org:
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
On Thu, Sep 25, 2014 at 9:35 AM, Chet Ramey chet.ra...@case.edu 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
On Wed, 24 Sep 2014 21:35:19 -0400, Chet Ramey chet.ra...@case.edu 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
On Thu, Sep 25, 2014 at 11:06 AM, lolilolicon loliloli...@gmail.com wrote:
On Thu, Sep 25, 2014 at 9:35 AM, Chet Ramey chet.ra...@case.edu 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,
2014-09-25 10:43 GMT+02:00 Davide Brini dave...@gmx.com:
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
On Thu, Sep 25, 2014 at 7:19 AM, Linda Walsh b...@tlinx.org 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
On Thu, Sep 25, 2014 at 12:42 PM, lolilolicon loliloli...@gmail.com wrote:
On Thu, Sep 25, 2014 at 7:19 AM, Linda Walsh b...@tlinx.org 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
On Thu, Sep 25, 2014 at 5:51 PM, Pierre Gaston pierre.gas...@gmail.com wrote:
On Thu, Sep 25, 2014 at 12:42 PM, lolilolicon loliloli...@gmail.com wrote:
On Thu, Sep 25, 2014 at 7:19 AM, Linda Walsh b...@tlinx.org wrote:
lolilolicon wrote:
I don't expect more than a dozen who rely on
On Thu, Sep 25, 2014 at 6:09 PM, Pierre Gaston pierre.gas...@gmail.com 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.
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
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
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
On 9/25/14, 6:12 AM, lolilolicon wrote:
On Thu, Sep 25, 2014 at 6:09 PM, Pierre Gaston pierre.gas...@gmail.com
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
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, that's
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);
* still expand the
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 purpose
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
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 invalid shell
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_login.
lolilolicon wrote:
On Thu, Sep 25, 2014 at 9:00 PM, Chet Ramey chet.ra...@case.edu 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
On Sep 25, 2014, at 2:47 PM, lolilolicon loliloli...@gmail.com wrote:
On Fri, Sep 26, 2014 at 2:28 AM, Ángel González an...@16bits.net 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
On 9/25/14, 2:47 PM, lolilolicon wrote:
On Fri, Sep 26, 2014 at 2:28 AM, Ángel González an...@16bits.net 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
On Fri, Sep 26, 2014 at 2:53 AM, Linda Walsh b...@tlinx.org 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
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 untrusted
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 to
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 what function
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
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
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 3:53 AM, Greg Wooledge wool...@eeg.ccf.org 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:
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 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='() {
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 work
On Sep 24, 2014, at 4:06 PM, lolilolicon loliloli...@gmail.com wrote:
On Thu, Sep 25, 2014 at 3:53 AM, Greg Wooledge wool...@eeg.ccf.org 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
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 going
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
50 matches
Mail list logo
