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 Thu, Sep 25, 2014 at 06:02:11AM -0700, gnu.bash.bug wrote:
Hi,
This patch does not seem to work on HP-UX:
Worked for me on 10.20.
$ /usr/bin/env x='() { :;}; echo vulnerable' bash -c 'echo hello'
vulnerable
hello
imadev:~$ uname -a
HP-UX imadev B.10.20 A 9000/785 2008897791 two-user
On 9/25/14, 9:02 AM, gnu.bash.bug wrote:
Hi,
This patch does not seem to work on HP-UX:
$ ./bash --version
GNU bash, version 4.3.25(1)-release (ia64-hp-hpux11.31)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
Ah great, thanks for that...though since there's still the bug in p025 (see
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169 ) I'll keep
spinning my wheels and watching the git branches until p026 rolls out.
ta,
Mark
On Thu, Sep 25, 2014 at 3:55 PM, Chris F.A. Johnson
Are you absolutely sure that the bash your command is invoking is
the patched one?
You are right! I had like 4 other bash versions in my PATH
So case closed... ;)
Thanks!
Michael
Good day Chet, bash-list -
I just checked out the latest git head, applied the bash43-025 patch, and built
$ ./bash --version
GNU bash, version 4.3.25(3)-release (x86_64-unknown-linux-gnu)
...
which PASSED its 'make check' test suite, both under Ubuntu 14.04.1 LTS
and under RHEL-6.5+ , on an
On Thu, Sep 25, 2014 at 02:50:03PM +0100, Jason Vas Dias wrote:
But now there is an issue - bash seems to lose its idea of stdout / stderr
being
a terminal within read loops, as illustrated by this test script (/tmp/t.sh):
quote
#!/bin/bash
tty
echo $'1\n2' test.list;
while read line;
Jason Vas Dias jason.vas.d...@gmail.com writes:
quote
#!/bin/bash
tty
echo $'1\n2' test.list;
while read line; do
tty;
done test.list
/quote
Its output illustrates the problem:
quote
$ ./bash /tmp/t.sh
/dev/pts/6
not a tty
not a tty
/quote
tty uses stdin, so this is the
Oops, sorry, this issue is nothing to do with the bash43-025 patch -
I just verified that the same issue occurs with bash 4.1.2(1) .
The issue was that a script that does an 'stty' command was
failing when run in a 'while read ... ' loop. It wasn't using
'stty -F', so was trying to stty on stdin,
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
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
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 not as
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
Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale'
Hello,
I've downloaded the source for bash 4.3 and all patches, patched the source to
Patch 25.
But according some description I've found (http://heise.de/-2403305 sorry, only
in German
available), you can test with the command
env x='() { :;}; echo vulnerable' bash -c echo this is a test
if
Is the response (workarounds and patch) being discussed elsewhere ?
(1) Patch
Looking at the code, it seems that the problem is that in
initialize_shell_variables(), when an inheritable function is detected in
the environment by the () { prefix, we then directly
call parse_and_execute(), on
I understand that some people might find function exports useful, but
there is also some utility in being able to turn it off.
I've added a configure flag, --disable-function-export which prevents
bash from attempting to parse environment variables that look like
functions upon startup. The
On 09/25/2014 08:48 AM, Alexandre Ferrieux wrote:
Is the response (workarounds and patch) being discussed elsewhere ?
(1) Patch
Looking at the code, it seems that the problem is that in
initialize_shell_variables(), when an inheritable function is detected in
the environment by the ()
On 09/25/2014 09:33 AM, ralf.naeg...@she.net wrote:
Hello,
I've downloaded the source for bash 4.3 and all patches, patched the source
to Patch 25.
But according some description I've found (http://heise.de/-2403305 sorry,
only in German
available), you can test with the command
env
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
On 9/24/14, 5:38 PM, Eric Blake wrote:
and I'd feel much more comfortable with exporting f()=... as the
backdoor for passing the function definition, _particularly_ since the
shell already allows functions and variables to co-exist:
We used to do that, and part of the code that I removed in
On Sep 25, 2014, at 5:42 PM, Alexandre FERRIEUX - SOFT/LAN
alexandre.ferri...@orange.com wrote:
On 25/09/2014 22:51, Eric Blake wrote:
On 09/25/2014 08:48 AM, Alexandre Ferrieux wrote:
Is the response (workarounds and patch) being discussed elsewhere ?
Thanks. Like thousands of people I
On 9/24/2014 6:07 PM, Thad Floryan wrote:
I caught the newsflash at Reuters earlier todat and a
search found the other URLs below. This seemed the only
relevant bash group available for subscription at the
eternal-september NNTP server.
Articles:
New 'Bash' software bug may pose bigger
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...
Earlier today I performed the `bash` security upgrade on my
| [userid~]uname -rs
| FreeBSD 10.0-RELEASE-p9
machine. I thought to check the version level of `bash` to
see what I now have:
| [userid~]man bash
| :
| :
| --version
| Show version information for this instance of
On 9/25/14, 9:41 PM, Allodoxaphobia wrote:
Earlier today I performed the `bash` security upgrade on my
| [userid~]uname -rs
| FreeBSD 10.0-RELEASE-p9
machine. I thought to check the version level of `bash` to
see what I now have:
I can't reproduce this. My patched version of bash gives
On Thu, 25 Sep 2014 23:04:46 -0400, Chet Ramey wrote:
On 9/25/14, 9:41 PM, Allodoxaphobia wrote:
Earlier today I performed the `bash` security upgrade on my
| [userid~]uname -rs
| FreeBSD 10.0-RELEASE-p9
machine. I thought to check the version level of `bash` to
see what I now have:
I
William Moss
billm...@acm.org
On my Debian system, they seem to have applied the fix for strcpy.
On my custom system, I recompiled bash 4.2 from source and when I tried to
apply the latest patch:
patch -b -i ./bash42-048 -p0 -o ./bash
I get
patching file ./bash
Hunk #1 succeeded at 36 with fuzz
On Friday, September 26, 2014 9:58:56 AM UTC+10, Chet Ramey wrote:
On 9/24/14, 5:38 PM, Eric Blake wrote:
and I'd feel much more comfortable with exporting f()=... as the
backdoor for passing the function definition, _particularly_ since the
shell already allows functions and
51 matches
Mail list logo
