On Thu, Sep 25, 2014 at 2:48 PM, Gerald Combs <gerald@xxxxxxxxxxxxx> wrote:
> On 9/25/14 10:59 AM, Graham Bloice wrote:
>> On 25 September 2014 18:54, Evan Huus <eapache@xxxxxxxxx
>> <mailto:eapache@xxxxxxxxx>> wrote:
>>
>> Anybody know why they started? It happened on one of my commits, but
>> as far as I can tell the error is
>>
>> 'C:\cygwin\bin\python2' is not recognized as an internal or
>> external command,
>>
>> which doesn't look related to my changes...
>>
>>
>> In general Windows builds should be picking up the native Windows python
>> as the cygwin one is pretty slow.
>
> For some reason CMake seems to be really good at finding Cygwin's Python
> instead of the python.org Python even though c:\Python27 comes before
> c:\cygwin\bin in PATH on the Windows builders. The problem is that
> Cygwin's python.exe is a symlink, which doesn't work too well when
> called outside Cygwin:
>
> http://public.kitware.com/Bug/view.php?id=13818
>
> As part of yesterday's "upgrade all copies of Bash everywhere"[1]
> exercise I upgraded all of the Cygwin packages on the Windows builders.
> This included a Python upgrade, which is required by AsciiDoc. I'll see
> if I can force CMake to find the right executable using
> -DPYTHON_EXECUTABLE but it would be nice if it could figure things out
> on its own.
>
>
> [1] If have Bash installed anywhere, drop what you're doing and upgrade
> it now. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
And if you were too on-the-ball yesterday you might need to upgrade it again:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169
Although to quote one of the security-ops people at my $DAY_JOB: "even
with a correct fix in place, the feature of being able to define
functions in your env-vars means that you could potentially override a
bunch of commands that people might execute, and still get arbitrary
code executed."