On Mon, Aug 17, 2015 at 6:15 PM, Eric Blake ebl...@redhat.com wrote:
snip
Fix your script to not do stupid things, like trying an insanely-large
brace expansion, or trying an 'eval' (or similar) on untrusted user
input. But don't call it a bash security hole that bash allows you to
write
On Monday, August 17, 2015 04:15:50 PM Eric Blake wrote:
On 08/17/2015 09:58 AM, Pasha K wrote:
Hey Greg,
I wasn't particularly trying to actually generate that large amount of
strings in memory, I wa purposely trying to overflow the integer variable
nelemhoping to get Code Execution.
On 08/17/2015 09:58 AM, Pasha K wrote:
Hey Greg,
I wasn't particularly trying to actually generate that large amount of
strings in memory, I wa purposely trying to overflow the integer variable
nelemhoping to get Code Execution. This could potentially be a security
risk as shell shock was
On Tue, Aug 18, 2015 at 07:54:48AM -0500, Dan Douglas wrote:
IMHO the issue of whether the integer is allowed to overflow is separate from
the question of whether the resulting expansion is too big. Code that does
an `eval blah{0..$n}` is reasonably common and not necessarily stupid.
Yes,
BASH PATCH REPORT
=
Bash-Release: 4.3
Patch-ID: bash43-041
Bug-Reported-by:Hanno Böck ha...@hboeck.de
Bug-Reference-ID: 20150623131106.6f111da9@pc1,
20150707004640.0e61d2f9@pc1
Bug-Reference-URL:
On 8/18/15, Chet Ramey chet.ra...@case.edu wrote:
On 8/17/15 4:19 AM, isabella parakiss wrote:
Quoting is necessary in a few cases:
$ var=foo; declare -A arr$var=([x]=y)
bash: warning: arrfoo=([x]=y): quoted compound array assignment
deprecated
$ var=foo; declare -A arr$var=([x]=y)
bash:
On Tuesday, August 18, 2015 9:54:55 AM CDT Isaac Good wrote:
Would you mind sharing the rational behind having it undocumented?
Since I like guessing: the syntax for parameter expansion operators is
currently non-extensible, so the namespace of terse operators is in limited
supply. New syntax
Sorry I meant to reply to that thread but ran out of time. I think Stephane's
eventual proposal was pretty close to what I had in mind but expressed badly.
I'm not sure why it was eventually decided to deprecate the current system
entirely but I'm not opposed to the idea - especially if it
Linda Walsh b...@tlinx.org writes:
Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
-x switch like 'find, cp, mv, et al.) no longer works to clean
out a directory stay on *one* file system.
Now rm will delete things on any number of file systems, as long
as they
On 8/18/15 1:52 PM, isabella parakiss wrote:
Sorry for being both pedantic and late for that discussion but what's the
point of this warning? From my understanding, the code is still valid, so
it doesn't stop a possible attacker and it only annoys regular users.
It's meant as an indication
On Tue, Aug 18, 2015 at 01:49:53PM -0700, Linda Walsh wrote:
Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
-x switch like 'find, cp, mv, et al.) no longer works to clean
out a directory stay on *one* file system.
When did POSIX or any historical Unix rm have a
Andreas Schwab wrote:
Linda Walsh b...@tlinx.org writes:
Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
-x switch like 'find, cp, mv, et al.) no longer works to clean
out a directory stay on *one* file system.
Now rm will delete things on any number of file systems, as
On 18 Aug 2015 13:34, Linda Walsh wrote:
Then can you give any technical reason why a static
lib that uses no network services (i.e. running
on a mini-root ) couldn't be made available for
the various calls that currently claim dynamic library
support is necessary.
(1)
On 18 Aug 2015 10:51, Chet Ramey wrote:
On 8/17/15 4:19 AM, isabella parakiss wrote:
Quoting is necessary in a few cases:
$ var=foo; declare -A arr$var=([x]=y)
bash: warning: arrfoo=([x]=y): quoted compound array assignment deprecated
$ var=foo; declare -A arr$var=([x]=y)
bash:
Mike Frysinger wrote:
On 18 Aug 2015 13:34, Linda Walsh wrote:
Then can you give any technical reason why a static
lib that uses no network services (i.e. running
on a mini-root ) couldn't be made available for
the various calls that currently claim dynamic library
support is necessary.
(1)
Mike Frysinger wrote:
it is not political, nor is it related to bash at all
-mike
Then can you give any technical reason why a static
lib that uses no network services (i.e. running
on a mini-root ) couldn't be made available for
the various calls that currently claim dynamic library
support
On 8/18/15 1:43 PM, Dan Douglas wrote:
On Tuesday, August 18, 2015 9:54:55 AM CDT Isaac Good wrote:
Would you mind sharing the rational behind having it undocumented?
Since I like guessing: the syntax for parameter expansion operators is
currently non-extensible, so the namespace of terse
Eric Blake wrote:
Like it or not, it is the historical behavior standardized by POSIX.
This is not true. POSIX no longer documents historical behavior,
but now dictates new, historically-incompatible behaviors for a
variety of features in a variety of products (not just BASH).
As such,
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale'
Greg Wooledge wrote:
On Tue, Aug 18, 2015 at 01:49:53PM -0700, Linda Walsh wrote:
Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
-x switch like 'find, cp, mv, et al.) no longer works to clean
out a directory stay on *one* file system.
When did POSIX or any historical
On Wed, 19 Aug 2015, Yan Pashkovsky wrote:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
On Tue, Aug 18, 2015 at 09:22:07AM -0500, Dan Douglas wrote:
The `~` is obviously inspired by the vim
movement to toggle caps.
~ is standard vi, not a vim extension.
BASH PATCH REPORT
=
Bash-Release: 4.3
Patch-ID: bash43-040
Bug-Reported-by:Jean Delvare jdelv...@suse.de
Bug-Reference-ID: 20150609180231.5f463695@endymion.delvare
Bug-Reference-URL:
On 8/18/15 9:12 AM, Dan Douglas wrote:
Actually I think I spoke too soon. There's already some considerable logic in
braces.c to check for overflow (e.g. around braces.c:390 shortly after
declaration of the int). Looks like there were some changes in this code last
year to beef it up a
On 8/17/15 4:19 AM, isabella parakiss wrote:
Quoting is necessary in a few cases:
$ var=foo; declare -A arr$var=([x]=y)
bash: warning: arrfoo=([x]=y): quoted compound array assignment deprecated
$ var=foo; declare -A arr$var=([x]=y)
bash: syntax error near unexpected token `('
$ var=foo;
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/ locale'
On 8/18/15 9:50 AM, Dan Douglas wrote:
Description:
The man page fails to document the ${var~} and ${var~~} case inversion
expansion.
It got the upper and lower, ie ${var^} and ${var,} but not invert.
Fix:
More documentation.
I'm pretty sure that's intentional. The corresponding
On Tuesday, August 18, 2015 09:04:33 AM Greg Wooledge wrote:
On Tue, Aug 18, 2015 at 07:54:48AM -0500, Dan Douglas wrote:
IMHO the issue of whether the integer is allowed to overflow is separate
from
the question of whether the resulting expansion is too big. Code that
does
an `eval
On Tuesday, August 18, 2015 08:50:51 AM Dan Douglas wrote:
I'm pretty sure that's intentional. The corresponding `declare -c` has never
been documented either.
Hrm, it doesn't correspond actually. declare -c just capitalizes the first
letter of the string.
Another thing about the ${var~}
BASH PATCH REPORT
=
Bash-Release: 4.3
Patch-ID: bash43-042
Bug-Reported-by:Nathan Neulinger nn...@neulinger.org
Bug-Reference-ID: 558efdf2.7060...@neulinger.org
Bug-Reference-URL:
On 8/15/15 9:02 PM, Sergey Tselikh wrote:
Description:
An incorrect conversion from indexed to associative array in bash script leads
bash interpreter to segfault (bash still gives a useful error report in this
situation,
which is good).
As seen in the output of GDB, bash terminates in
Would you mind sharing the rational behind having it undocumented?
On Tue, Aug 18, 2015 at 7:38 AM, Chet Ramey chet.ra...@case.edu wrote:
On 8/18/15 9:50 AM, Dan Douglas wrote:
Description:
The man page fails to document the ${var~} and ${var~~} case inversion
expansion.
It got the
Clark Wang wrote:
I had the same problem months ago. See Chet's answer:
http://lists.gnu.org/archive/html/bug-bash/2014-03/msg00069.html
===
Yep though I'm not sure about the reasoning in providing
different behaviors based on default-dir-expansion == convert
all relative paths to
2015-08-17 10:19:00 +0200, isabella parakiss:
Quoting is necessary in a few cases:
$ var=foo; declare -A arr$var=([x]=y)
bash: warning: arrfoo=([x]=y): quoted compound array assignment deprecated
$ var=foo; declare -A arr$var=([x]=y)
bash: syntax error near unexpected token `('
$ var=foo;
34 matches
Mail list logo
