I fixed the bug in ksh that allows you delete a special builtin.
On Mon, Sep 29, 2014 at 5:25 PM, Dan Douglas wrote:
> Just a few points to add.
>
> On Monday, September 29, 2014 04:29:52 PM Stephane Chazelas wrote:
> > 2014-09-29 09:04:00 -0600, Eric Blake:
> > [...]
> > > > "The function is
On 9/29/14, 5:25 PM, Dan Douglas wrote:
> This doesn't normally matter because POSIX requires special builtins to take
> precedence over functions during command search, so even if you have such a
> function defined it is impossible to call. Bash doesn't use the correct
> search
> order howeve
On 9/29/14, 7:53 PM, Alexandre Ferrieux wrote:
> On Tuesday, September 30, 2014 1:40:55 AM UTC+2, Chet Ramey wrote:
>>
>>> Forget about posix mode then: bash -p (privileged) offers a lean-and-mean
>>> variant which pretty much satisfies anybody needing "just sh". However,
>>> there is no way to s
On Tuesday, September 30, 2014 1:40:55 AM UTC+2, Chet Ramey wrote:
>
> > Forget about posix mode then: bash -p (privileged) offers a lean-and-mean
> > variant which pretty much satisfies anybody needing "just sh". However,
> > there is no way to store an option in a symbolic link, so all distrib
On 9/26/14, 8:58 PM, Nathan McGarvey wrote:
> Pardon my catching up. This (and all the other related patches for
> other past versions) is to remedy CVE-2014-7169 and CVE-2014-6271 was
> remedied by the previous Patch 25 (and related set for all other versions.)
> Is this correct? Or are there
On 9/29/14, 5:46 PM, Alexandre Ferrieux wrote:
> Forget about posix mode then: bash -p (privileged) offers a lean-and-mean
> variant which pretty much satisfies anybody needing "just sh". However, there
> is no way to store an option in a symbolic link, so all distributions doing
> "sh -> bash"
On Tuesday, September 30, 2014 12:11:15 AM Andreas Schwab wrote:
> Dan Douglas writes:
>
> > Another thing you can do in bash is bypass its command name check by using
> > a
> > null zeroth word.
> >
> > $ { function } { echo test; }; <() }; }
> > test
> >
> > Ordinarily } would be uncallable,
Dan Douglas writes:
> Another thing you can do in bash is bypass its command name check by using a
> null zeroth word.
>
> $ { function } { echo test; }; <() }; }
> test
>
> Ordinarily } would be uncallable,
Only literal } is special, you can use \} instead, or store it in a
variable.
Andreas.
Linda Walsh wrote:
> wrote:
> > The change only affects environment variables **loaded as exported
> > functions**. Bash won't forbid you from using / inside the name of an
> > environment variables.
> >
>
> The below doesn't demonstrate bash doing anything with the variable you
> decla
On Monday, September 29, 2014 9:51:45 PM UTC+2, Chet Ramey wrote:
> >
> > So it seems the order is wrong. As a consequence, and this is confirmed by
> > experience, the #!/bin/sh prefix behaves as featuristic bash.
> > My suggestion then is to undo that mistake.
>
> Posix mode was never intended
Just a few points to add.
On Monday, September 29, 2014 04:29:52 PM Stephane Chazelas wrote:
> 2014-09-29 09:04:00 -0600, Eric Blake:
> [...]
> > > "The function is named fname; the application shall ensure that it is a
> > > name (see XBD Name) and that it is not the name of a special built-in
u
Configuration Information:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-g$
uname output: Linux compiler 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4 11:26:59
UTC 2012 x86
Configuration Information:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-g$
uname output: Linux compiler 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4 11:26:59
UTC 2012 x86
On 9/27/14, 1:00 AM, V S, Nagendra (Nonstop Filesystems Team) wrote:
> Hi Chet,
> Thanks a lot for the patch.
>
> The official bash patch & the patch that you posted on openwall forum seems
> to be different. The official bash patch does not contain this
>
> *** ../bash-4.2.48/y.tab.c 2012
On 9/26/14, 4:29 PM, Alexandre Ferrieux wrote:
> On Friday, September 26, 2014 10:00:08 AM UTC+2, Andreas Schwab wrote:
>> Alexandre Ferrieux writes:
>>
>>> So, what about, in bash's initialization, detecting that we are invoked as
>>> "/bin/sh",
>>
>> It already does. See (bash) Bash POSIX Mode.
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
Deron Meranda wrote:
> On an unrelated note, I have also tried to compare sources against the
> Savannah Git repository, and I noted that the repository has a couple small
> differences from the FTP files + patches.
>
> The Git repo has a blank file called "-i", probably an accident of some
> comm
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
2014-09-29 09:04:00 -0600, Eric Blake:
[...]
> I would expect something like "It shall be an error if fname is the name
> of a special built-in utility", as _that_ would be a hard requirement on
> bash, not just the application. Maybe we have a bug in the POSIX spec
> for a missing requirement.
[.
2014-09-29 09:04:00 -0600, Eric Blake:
[...]
> > "The function is named fname; the application shall ensure that it is a
> > name (see XBD Name) and that it is not the name of a special built-in
> > utility."
> >
> > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_
On 9/28/14, 7:02 PM, rain.back...@gmail.com wrote:
> Bash Version: 4.3
> Patch Level: 27
> Release Status: release
>
> Description:
> This is a bug affecting the latest of the shellshock patches at the time of
> writing, 4.3.27. If bash is configured and built on a system with no
> libte
[adding Austin Group]
On 09/28/2014 07:11 PM, Chet Ramey wrote:
> On 9/27/14, 10:03 PM, Eric Blake wrote:
>
>>> Yes, it's an application requirement. Regardless, all the versions of bash
>>> we're talking about here reject non-identifiers.
>>
>> I'm still trying to find that line in the actual P
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
2014-09-27 23:53:12 +0200, Arfrever Frehtes Taifersar Arahesis:
[...]
> Ability to export/import functions with "=" in function names
> could be achieved by not embedding function names in
> environmental variables and using a single BASH_FUNCTIONS
> environmental variable whose value would contain
2014-09-27 22:48:44 -0600, Eric Blake:
> On 09/27/2014 08:50 PM, Chet Ramey wrote:
> > BASH PATCH REPORT
> > =
>
> > /* Don't import function names that are invalid identifiers from the
> > environment, though we stil
On Mon, Sep 29, 2014 at 05:11:52PM +0800, ??? wrote:
> /bin/echo: line 1: Mon: command not found
> make: *** [.build] Error 127
This is just a guess, but it looks like you tried to build bash in a
shell where you had previously been testing for shellshock-type
vulnerabilities, and you have a conta
On 9/29/14, 8:22 AM, Notes Jonny wrote:
> Hello
> I noticed hash_search() did not check if "string" parameter was
> non-NULL. Please find attached a patch for this.
It's the caller's responsibility to ensure that the string passed to
hash_search is non-NULL.
Chet
--
``The lyf so short, the craf
Hello
I noticed hash_search() did not check if "string" parameter was
non-NULL. Please find attached a patch for this.
There are others similar. So I will wait and see if you are happy with
these kind of changes, and if so I can submit more when I have
analysed.
I'm not on this list, so please in
> I'd send it to your vendor. If appropriate they can send it upstream.
>
>
>
> Chet
I've sent this to a debian person following advice on the Arch list I initially
asked. I probably won't get used as I imagine they'll want a more general
approach to all the various versions of the bash fixe
29 matches
Mail list logo
