[ANNOUNCEMENT] Updated: bash-4.1.13-6

[ANNOUNCEMENT] Updated: bash-4.1.13-6

[Eric Blake (cygwin)]

[-- Attachment #1: Type: text/plain, Size: 7518 bytes --]

A new release of bash, 4.1.13-6, has been uploaded and will soon reach a
mirror near you; leaving the previous version at 4.12-5.

NEWS:
=====
This is a minor rebuild which picks up an upstream patch to fix
CVE-2014-7169, as well as a Red Hat patch to ensure that CVE-2014-7186
and CVE-2014-7187 cannot be exploited as ShellShock attacks (I did not
actually fix the parser bugs of the latter two CVEs, so you can still
crash bash with deeply nested heredocs; but such a crash can no longer
be triggered by arbitrary contents of a normal shell variable, which is
the key to what forms a ShellShock attack).  Left unpatched, a
vulnerable version of bash could allow arbitrary code execution via
specially crafted environment variables, and was exploitable through a
number of remote services, so it is highly recommended that you upgrade.
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/
https://access.redhat.com/articles/1200223
https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00238.html

I also turned on the (undocumented) 'bash --wordexp' mode (actually,
that happened in 4.1.12-5, although I failed to mention it at the time),
which allows the C library call wordexp() to now function.

I also hope to have a build of bash 4.3 available soon, but wanted to
get the CVE fixed as soon as possible due to its severity.

There are a few things you should be aware of before using this version:
1. When using binary mounts, cygwin programs try to emulate Linux.  Bash
on Linux does not understand \r\n line endings, but interprets the \r
literally, which leads to syntax errors or odd variable assignments.
Therefore, you will get the same behavior on Cygwin binary mounts by
default.
2. d2u is your friend.  You can use it to convert any problematic script
into binary line endings.
3. Cygwin text mounts automatically work with either line ending style,
because the \r is stripped before bash reads the file.  If you
absolutely must use files with \r\n line endings, consider mounting the
directory where those files live as a text mount.  However, text mounts
are not as well tested or supported on the cygwin mailing list, so you
may encounter other problems with other cygwin tools in those directories.
4. This version of bash has a cygwin-specific set option, named "igncr",
to force bash to ignore \r, independently of cygwin's mount style.  As
of bash-3.2.3-5, it controls regular scripts, command substitution, and
sourced files.  I hope to convince the upstream bash maintainer to
accept this patch into a future bash release even on Linux, rather than
keeping it a cygwin-specific patch, but only time will tell.  There are
several ways to activate this option:
4a. For a single affected script, add this line just after the she-bang:
 (set -o igncr) 2>/dev/null && set -o igncr; # comment is needed
4b. For a single script, invoke bash explicitly with the option, as in
'bash -o igncr ./myscript' rather than the simpler './myscript'.
4c. To affect all scripts, export the environment variable BASH_ENV,
pointing to a file that sets the shell option as desired.  Bash will
source this file on startup for every script.
4d. Added in the bash-3.2-2 release: export the environment variable
SHELLOPTS with igncr included in it.  It is read-only from within bash,
but you can set it before invoking bash; once in bash, it auto-tracks
the current state of 'set -o igncr'.  If exported, then all bash child
processes inherit the same option settings; with the exception added in
3.2.9-11 that certain interactive options are not inherited in
non-interactive use.
4e. bash-4.1.9-1 dropped support for 'shopt -s igncr'; it did not make
sense to support the option through both set and shopt, and SHELLOPTS
proved to be more powerful.
5. You can also experiment with the IFS variable for controlling how
bash will treat \r during variable expansion.
6. There are varying levels of speed at which bash operates.  The
fastest is on a binary mount with igncr disabled (the default behavior).
 Next would be text mounts with igncr disabled and no \r in the
underlying file. Next would be binary mounts with igncr enabled.  And
the slowest that bash will operate is on text mounts with igncr enabled.
7. As additional cygwin extensions, this version of bash includes:
7a. EXECIGNORE - a colon-separated list of glob patterns to ignore
when completing on executables.  EXECIGNORE=*.dll is common.
7b. completion_strip_exe - using 'shopt -s completion_strip_exe'
makes completion strip .exe suffixes
8. This version of bash is immune to ShellShock (CVE-2014-6271 and
friends) because it exports functions via 'BASH_FUNC_foo()=' rather than
'foo=' environment variables.  This is different than the current
upstream, but leads to saner behavior and matches what Fedora does.
9. If you don't like how bash behaves, then propose a patch, rather than
proposing idle ideas.  This turn of events has already been talked to
death on the mailing lists by people with many ideas, but few patches.
Thanks to Dan Colascione for providing the EXECIGNORE and
completion_strip_exe patches.

Remember, you must not have any bash or /bin/sh instances running when
you upgrade the bash package.  This release requires cygwin-1.7.32-1 or
later; and it requires libreadline7-6.1.2-2 or later.  See also the
upstream documentation in /usr/share/doc/bash/.

DESCRIPTION:
============
Bash is an sh-compatible shell that incorporates useful features from
the Korn shell (ksh) and C shell (csh).  It is intended to conform to
the IEEE POSIX P1003.2/ISO 9945.2 Shell and Tools standard.  It offers
functional improvements over sh for both programming and interactive
use. In addition, most sh scripts can be run by Bash without modification.

As of the bash 3.0 series, cygwin /bin/sh defaults to bash, not ash,
similar to some Linux distributions (although /bin/sh may swap to dash
at some future time).

UPDATE:
=======
To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system. Save it and run setup, answer the questions and pick up 'bash'
in the 'Base' category (it should already be selected).  As this is an
experimental release, you will need to use the 'Exp' radio button.

DOWNLOAD:
=========
Note that downloads from cygwin.com aren't allowed due to bandwidth
limitations.  This means that you will need to find a mirror which has
this update, please choose the one nearest to you:
http://cygwin.com/mirrors.html

QUESTIONS:
==========
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

-- 
Eric Blake
volunteer cygwin bash package maintainer

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=================================
To unsubscribe to the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message.  Send
email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-YOU=YOURDOMAIN.COM@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

RE: [ANNOUNCEMENT] Updated: bash-4.1.13-6

[Buchbinder, Barry (NIH/NIAID) [E]]

Eric Blake (cygwin) sent the following at Saturday, September 27, 2014 2:14 AM
>I also turned on the (undocumented) 'bash --wordexp' mode (actually,
>that happened in 4.1.12-5, although I failed to mention it at the time),
>which allows the C library call wordexp() to now function.

From a user standpoint, why would one want to use --wordexp?  What is the
effect of turning on this mode?

Thanks,

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

Re: [ANNOUNCEMENT] Updated: bash-4.1.13-6

[Yaakov Selkowitz]

On 2014-09-29 09:18, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> Eric Blake (cygwin) sent the following at Saturday, September 27, 2014 2:14 AM
>> I also turned on the (undocumented) 'bash --wordexp' mode (actually,
>> that happened in 4.1.12-5, although I failed to mention it at the time),
>> which allows the C library call wordexp() to now function.
>
>  From a user standpoint, why would one want to use --wordexp?  What is the
> effect of turning on this mode?

It's not meant to be used by users.  It exists solely to be used by libc 
(cygwin) as an implementation of wordexp(3).


Yaakov


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: bash-4.1.13-6

[Achim Gratz]

Eric Blake (cygwin) writes:
> A new release of bash, 4.1.13-6, has been uploaded and will soon reach a
> mirror near you; leaving the previous version at 4.12-5.

Just out of curiosity, why is this release version -6 instead of -1?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] Updated: bash-4.1.13-6

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

On 09/29/2014 10:14 AM, Achim Gratz wrote:
> Eric Blake (cygwin) writes:
>> A new release of bash, 4.1.13-6, has been uploaded and will soon reach a
>> mirror near you; leaving the previous version at 4.12-5.
> 
> Just out of curiosity, why is this release version -6 instead of -1?

Because of how upstream bash numbers things.  They only ship a 4.1
tarball, and then 13 official patches that must be applied by the
maintainer on top of that 4.1 tarball.  However, it modifies the micro
version number according to which upstream patches have been applied.
So, this is my sixth time building bash 4.1 for cygwin, and it's just
that bash's micro number bumped from 4.1.12 to 4.1.13 in between my -5
and -6 builds.

When I eventually get bash 4.3 out the door, it will start at 4.3.27-1
(or a higher micro, as there is still a lot of churn in upstream bash to
now patch lower-priority bugs that are no longer Shell Shock attacks
thanks to patch 27, but which are still local crashers).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

Re: [ANNOUNCEMENT] Updated: bash-4.1.13-6

[Achim Gratz]

Eric Blake writes:
> On 09/29/2014 10:14 AM, Achim Gratz wrote:
>> Eric Blake (cygwin) writes:
>>> A new release of bash, 4.1.13-6, has been uploaded and will soon reach a
>>> mirror near you; leaving the previous version at 4.12-5.
>> 
>> Just out of curiosity, why is this release version -6 instead of -1?
>
> Because of how upstream bash numbers things.
[...]

Thanks.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: [ANNOUNCEMENT] Updated: bash-4.1.13-6

[Buchbinder, Barry (NIH/NIAID) [E]]

Eric Blake (cygwin) sent the following at Saturday, September 27, 2014 2:14 AM

Using the new version of bash, two scripts that I use have both started giving me
the following error message(s).

/usr/bin/bash: error importing function definition for `BASH_FUNC_make-log'
/usr/bin/bash: error importing function definition for `BASH_FUNC_configure-log'
/usr/bin/bash: error importing function definition for `BASH_FUNC_prt-alias'

I was able to get rid of this by commenting out the functions (make-log,
configure-log, and prt-alias) and removing them from the list of functions being
set and exported in ~/.bashrc.  I rarely use these functions and would be unlikely
to use them in a subshell so that works as a solution.

What makes this strange is that I have other shell functions that are defined in
~/.bashrc and exported.  They have not shown up in the error messages.  As it
happens, the problem functions are the last 3 on the export list.  However,
adding another function to be exported doesn't cause a new error message for
just one function that is now at the end of the export list.

Another thing happening is that some scripts are now sometimes giving this error
message, but only when the problem function exports are not being exported.

Segmentation fault (core dumped)

Any hints about what I should look for to make export of my bash shell functions
reliable?

Thanks,

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

Re: [ANNOUNCEMENT] Updated: bash-4.1.13-6

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]

On 09/29/2014 03:23 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> Eric Blake (cygwin) sent the following at Saturday, September 27, 2014 2:14 AM
> 
> Using the new version of bash, two scripts that I use have both started giving me
> the following error message(s).
> 
> /usr/bin/bash: error importing function definition for `BASH_FUNC_make-log'
> /usr/bin/bash: error importing function definition for `BASH_FUNC_configure-log'
> /usr/bin/bash: error importing function definition for `BASH_FUNC_prt-alias'

These functions contain '-' in their name; that's a limitation of the
downstream forked patch I applied early to get 4.1.13-6 out the door.
Upstream solved it in a nicer manner, so you can once again have
functions with '-' in the name.  Please try again with the just-released
4.1.14-7.

> 
> I was able to get rid of this by commenting out the functions (make-log,
> configure-log, and prt-alias) and removing them from the list of functions being
> set and exported in ~/.bashrc.  I rarely use these functions and would be unlikely
> to use them in a subshell so that works as a solution.

Having the function wasn't the problem, it was exporting it.  You can
still have the function even in 4.1.13-6, as long as you don't export it.

> 
> Another thing happening is that some scripts are now sometimes giving this error
> message, but only when the problem function exports are not being exported.
> 
> Segmentation fault (core dumped)

Umm, that's not good. Can you please come up with a minimal reproduction
formula?  Which program is dumping core? Bash, or something else?  Is it
due to trying to execute the function that was not imported?

> 
> Any hints about what I should look for to make export of my bash shell functions
> reliable?

Upgrading to the next version :)


-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

RE: [ANNOUNCEMENT] Updated: bash-4.1.13-6

[Buchbinder, Barry (NIH/NIAID) [E]]

Eric Blake sent the following at Monday, September 29, 2014 5:29 PM
>On 09/29/2014 03:23 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
>> Eric Blake (cygwin) sent the following at Saturday, September 27, 2014 2:14 AM
>>
>> Using the new version of bash, two scripts that I use have both started giving me
>> the following error message(s).
>>
>> /usr/bin/bash: error importing function definition for `BASH_FUNC_make-log'
>> /usr/bin/bash: error importing function definition for `BASH_FUNC_configure-log'
>> /usr/bin/bash: error importing function definition for `BASH_FUNC_prt-alias'
>
>These functions contain '-' in their name; that's a limitation of
>the downstream forked patch I applied early to get 4.1.13-6 out the
>door. Upstream solved it in a nicer manner, so you can once again have
>functions with '-' in the name. Please try again with the just-released
>4.1.14-7.

I understand that to mean that 4.1.14-7 will be able to export functions with '-' in
their names.

>> I was able to get rid of this by commenting out the functions (make-log,
>> configure-log, and prt-alias) and removing them from the list of functions being
>> set and exported in ~/.bashrc.  I rarely use these functions and would be unlikely
>> to use them in a subshell so that works as a solution.
>
>Having the function wasn't the problem, it was exporting it. You can
>still have the function even in 4.1.13-6, as long as you don't export
>it.

Changed to underscores.  All is well.

>> Another thing happening is that some scripts are now sometimes giving this error
>> message, but only when the problem function exports are not being exported.
>>
>> Segmentation fault (core dumped)
>
>Umm, that's not good. Can you please come up with a minimal reproduction
>formula? Which program is dumping core? Bash, or something else? Is it
>due to trying to execute the function that was not imported?

It wasn't reproducible, but a while after I sent my email various windows stopped
responding, I couldn't close them, the machine wouldn't shut down, and ended up
unplugging the machine so I could reboot.  Let's assume that something unrelated
to cygwin was going on.

>> Any hints about what I should look for to make export of my bash shell functions
>> reliable?
>
>Upgrading to the next version :)

Will do!

Thanks for all your help.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

Re: [ANNOUNCEMENT] Updated: bash-4.1.13-6

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

On 09/29/2014 04:52 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
>> These functions contain '-' in their name; that's a limitation of
>> the downstream forked patch I applied early to get 4.1.13-6 out the
>> door. Upstream solved it in a nicer manner, so you can once again have
>> functions with '-' in the name. Please try again with the just-released
>> 4.1.14-7.
> 
> I understand that to mean that 4.1.14-7 will be able to export functions with '-' in
> their names.

Correct; also, I already verified it worked locally for me to export a
function with '-' when using 4.1.14-7.

> 
>>> I was able to get rid of this by commenting out the functions (make-log,
>>> configure-log, and prt-alias) and removing them from the list of functions being
>>> set and exported in ~/.bashrc.  I rarely use these functions and would be unlikely
>>> to use them in a subshell so that works as a solution.
>>
>> Having the function wasn't the problem, it was exporting it. You can
>> still have the function even in 4.1.13-6, as long as you don't export
>> it.
> 
> Changed to underscores.  All is well.

Also an option. :)

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]