Re: getaddrinfo fails with EAI_NODATA for some valid hosts with A records

2016-01-08 Thread Corinna Vinschen 
Hi Brian,

On Jan  7 15:39, Brian Inglis wrote:
> getaddrinfo fails with err 7 EAI_NODATA for some valid hosts with A records. 
> Err 7 EAI_NODATA is mapped from WSANO_DATA err 11004 in Windows.
> Can anyone reproduce failure with problem host name below? 

Yes, I can reproduce it, and it's a total surprise.

In fact, this is *not* a Cygwin problem.  I created an STC, a simple
mingw application, very certainly not using Cygwin at all:

$ cat gai.c
#define _WIN32_WINNT 0x0a00
#include 
#include 
#include 

#ifndef AI_DISABLE_IDN_ENCODING
#define AI_DISABLE_IDN_ENCODING 0x8
#endif

int
main (int argc, char **argv)
{
  WSADATA wsadata;
  struct addrinfo hint, *res;
  int ret;

  WSAStartup (MAKEWORD(2,2), &wsadata);

  memset (&hint, 0, sizeof hint);
  hint.ai_flags = 0;//AI_V4MAPPED | AI_ADDRCONFIG | AI_CANONNAME | 
AI_DISABLE_IDN_ENCODING;
  hint.ai_family = 0;//AF_INET;
  ret = getaddrinfo (argv[1], NULL, &hint, &res);
  printf ("ret = %d\n", ret);
}
$ x86_64-w64-mingw32-gcc -g -o gai gai.c -lws2_32
$ ./gai cygwin.org
ret = 0
$ ./gai www.sun.de
ret = 0
$ ./gai leapsecond.utcd.org
ret = 11004

I have no idea why Windows' getaddrinfo chokes on leapsecond.utcd.org
at all.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Pipes Again -- a simple test case

2016-01-08 Thread Corinna Vinschen 
On Jan  4 10:24, Houder wrote:
> On 2016-01-04 09:52, Marco Atzeri wrote:
> >On 04/01/2016 09:03, Houder wrote:
> >>Hi Corinna,
> >>
> >>I have been looking for an STC to show why cmp fails on Cygwin (and to
> >>show the
> >>difference between Cygwin and Linux).
> >>
> >>The STC below creates a pipe (pipe() is used), followed by calls to
> >>fstat() and
> >>stat() for both the read end and the write end of the pipe.
> >>
> >>(I also tested with popen()/pclose(): same result)
> >>
> >>Regards,
> >>Henri

Thanks for the STC.  However, given how this stuff works internally,
I have no good solution off the top of my head.  I played with various
ideas but to no avail.  I add this to my TODO list, but I probably
won't have a quick solution :(


Thanks,
Corinna


P.S: It would be really helpful if you could stick to the original
 thread and simply use "reply-to" once a discussion has started.
 It's very confusing having to connect the various threads.  Thanks.

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Pipes Again -- a simple test case

2016-01-08 Thread Houder 

On 2016-01-08 16:19, Corinna Vinschen wrote:

On Jan  4 10:24, Houder wrote:

On 2016-01-04 09:52, Marco Atzeri wrote:
>On 04/01/2016 09:03, Houder wrote:
>>Hi Corinna,
>>
>>I have been looking for an STC to show why cmp fails on Cygwin (and to
>>show the
>>difference between Cygwin and Linux).
>>
>>The STC below creates a pipe (pipe() is used), followed by calls to
>>fstat() and
>>stat() for both the read end and the write end of the pipe.
>>
>>(I also tested with popen()/pclose(): same result)
>>
>>Regards,
>>Henri


Thanks for the STC.  However, given how this stuff works internally,
I have no good solution off the top of my head.  I played with various
ideas but to no avail.  I add this to my TODO list, but I probably
won't have a quick solution :(


Thanks,
Corinna


P.S: It would be really helpful if you could stick to the original
 thread and simply use "reply-to" once a discussion has started.
 It's very confusing having to connect the various threads.  
Thanks.


Perhaps David B. can be helped by a Cygwin-specific patching to "cmp"? 
Eric?


... replacing the call to fstat() by a call to stat() ...
(as shown in https://cygwin.com/ml/cygwin/2015-12/msg00348.html)

By the way, thank you for reporting back to "us" about this. I already
feared that a "general" solution would have to wait ... You have already
too much on your plate.

As a final point, I also tested FIFOs and (unix domain) sockets.

FIFOs pass the test, sockets do not.

Regards,

Henri

--
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: cygwin.dll: bug with select on Windows console

2016-01-08 Thread Corinna Vinschen 
On Jan  7 13:18, John Hood wrote:
> Sorry about forgetting the testcase (which was good, actually, that
> version had a bug).  I've attached it here.  This takes a single
> argument, the timeout value for select() in microseconds.  A value of
> 100 is fine for testing this issue.  Type at it, or just bang on the
> keyboard with random keystrokes, and it will report the results from
> select() and the characters read.  On a Windows console, it should
> report an error within a few seconds.  Moving the mouse cursor over the
> Windows console window while typing seems to provoke the error as well. 

No chance.  I tried this for a good hour now with the unpatched Cygwin
DLL on 32 bit W7 and 64 bit W10 in 32 and 64 bit in a Windows console,
and I can't provoke this error.  It just works for me.

> On mintty or any other pty, the error never occurs.
> 
> I've been unable to build Cygwin from Git on my 32-bit install on Win7,
> thanks to various header mismatches and missing packages-- I think the
> latest was a mingw-gcc header, but I can't check that machine now.  The
> FAQ entry on how to build Cygwin is quite incomplete.  Are there any
> better directions for building Cygwin?

What exactly is failing?  If you installed all the packages mentioned in
the FAQ entry, plus building outside the source tree as outlined, you
should be fine.  Alternatively, install the cygport package and the
2.4.0-0.16 source package and build that via

  cygport cygwin.cygport prep compile

That should get you started.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: Pipes Again -- a simple test case

2016-01-08 Thread Corinna Vinschen 
On Jan  8 17:12, Houder wrote:
> On 2016-01-08 16:19, Corinna Vinschen wrote:
> >On Jan  4 10:24, Houder wrote:
> >>On 2016-01-04 09:52, Marco Atzeri wrote:
> >>>On 04/01/2016 09:03, Houder wrote:
> Hi Corinna,
> 
> I have been looking for an STC to show why cmp fails on Cygwin (and to
> show the
> difference between Cygwin and Linux).
> 
> The STC below creates a pipe (pipe() is used), followed by calls to
> fstat() and
> stat() for both the read end and the write end of the pipe.
> 
> (I also tested with popen()/pclose(): same result)
> 
> Regards,
> Henri
> >
> >Thanks for the STC.  However, given how this stuff works internally,
> >I have no good solution off the top of my head.  I played with various
> >ideas but to no avail.  I add this to my TODO list, but I probably
> >won't have a quick solution :(
> >
> >
> >Thanks,
> >Corinna
> >
> >
> >P.S: It would be really helpful if you could stick to the original
> > thread and simply use "reply-to" once a discussion has started.
> > It's very confusing having to connect the various threads.  Thanks.
> 
> Perhaps David B. can be helped by a Cygwin-specific patching to "cmp"? Eric?
> 
> ... replacing the call to fstat() by a call to stat() ...
> (as shown in https://cygwin.com/ml/cygwin/2015-12/msg00348.html)
> 
> By the way, thank you for reporting back to "us" about this. I already
> feared that a "general" solution would have to wait ... You have already
> too much on your plate.
> 
> As a final point, I also tested FIFOs and (unix domain) sockets.
> 
> FIFOs pass the test, sockets do not.

Yes, that's expected.  The underlying hack^Wmethod is the same for sockets
and pipes, while FIFOs have a real path on a real filesystem and thus have
a real inode number to fetch in stat/fstat.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: getaddrinfo fails with EAI_NODATA for some valid hosts with A records

2016-01-08 Thread cyg Simple 
On 1/8/2016 6:14 AM, Corinna Vinschen wrote:
> $ ./gai leapsecond.utcd.org
> ret = 11004
> 
> I have no idea why Windows' getaddrinfo chokes on leapsecond.utcd.org
> at all.

utcd.org doesn't resolve for me.  So getaddrinfo has no info to get.

-- 
cyg Simple

--
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: getaddrinfo fails with EAI_NODATA for some valid hosts with A records

2016-01-08 Thread Corinna Vinschen 
On Jan  8 13:44, cyg Simple wrote:
> On 1/8/2016 6:14 AM, Corinna Vinschen wrote:
> > $ ./gai leapsecond.utcd.org
> > ret = 11004
> > 
> > I have no idea why Windows' getaddrinfo chokes on leapsecond.utcd.org
> > at all.
> 
> utcd.org doesn't resolve for me.  So getaddrinfo has no info to get.

Why then does it work on Linux?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: getaddrinfo fails with EAI_NODATA for some valid hosts with A records

2016-01-08 Thread Stephen John Smoogen 
On 8 January 2016 at 11:44, cyg Simple  wrote:
> On 1/8/2016 6:14 AM, Corinna Vinschen wrote:
>> $ ./gai leapsecond.utcd.org
>> ret = 11004
>>
>> I have no idea why Windows' getaddrinfo chokes on leapsecond.utcd.org
>> at all.
>
> utcd.org doesn't resolve for me.  So getaddrinfo has no info to get.
>

utcd.org does not resolve. leapsecond.utcd.org does resolve.

leapsecond.utcd.org has address 244.34.36.97

> --
> cyg Simple
>
> --
> 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
>



-- 
Stephen J Smoogen.

--
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: Cannot Run Executable Files

2016-01-08 Thread Warren Young 
On Jan 7, 2016, at 9:59 PM, Yaakov Selkowitz  wrote:
> 
> On 2016-01-07 20:14, Zac G. Al Wakeel wrote:
>> Thank you Warren, it worked. But what would you suggest for future? I can't
>> leave the machine without antivirus
> 
> Start by choosing one NOT on this list:
> 
> https://cygwin.com/faq/faq.html#faq.using.bloda

Are you certain that Windows Defender belongs on that list?  I’ve run it for 
years without problems.

Microsoft has different incentives to provide antimalware software than the 
third-party commercial providers, which I find provides better outcomes:

1. Defender doesn’t have to trigger all kinds of false positives to “prove” 
that it’s doing things for you, so you’re scared into paying them again next 
year.

2. It’s from the OS provider, so it naturally does its thing using MS-provided 
mechanisms, instead of the shady API hooking that other antimalware providers 
use.

3. Microsoft would prefer that you believe there is no malware problem, so it 
takes as few running resources as possible, and pops up only when it’s really 
necessary.

IMHO, there is no reason to run anything other than Microsoft’s antimalware 
offerings.  Microsoft finally took ownership of this problem, and is now doing 
a good job of trying to solve it.
--
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: Cannot Run Executable Files

2016-01-08 Thread Warren Young 
On Jan 7, 2016, at 7:14 PM, Zac G. Al Wakeel  wrote:
> 
> Thank you Warren, it worked. But what would you suggest for future? I can't 
> leave the machine without antivirus 

For the archives, would you say which software was causing the problem?
--
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: [PWNED/DOSSED] Cygwin's setup-x86.exe loads and executes rogue DLL from its application directory

2016-01-08 Thread Yaakov Selkowitz 

On 2016-01-06 08:17, Stefan Kanthak wrote:
[snip]

I am analyzing this and working on a response, which I hope to have 
early next week.


--
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: getaddrinfo fails with EAI_NODATA for some valid hosts with A records

2016-01-08 Thread Andy Hall 
> 
> On Jan  8 13:44, cyg Simple wrote:
> > On 1/8/2016 6:14 AM, Corinna Vinschen wrote:
> > > $ ./gai leapsecond.utcd.org
> > > ret = 11004
> > >
> > > I have no idea why Windows' getaddrinfo chokes on leapsecond.utcd.org
> > > at all.
> >
> > utcd.org doesn't resolve for me.  So getaddrinfo has no info to get.
> 
> Why then does it work on Linux?
> 

nslookup works for me:

Win7 64-bit

$ nslookup leapsecond.utcd.org
Non-authoritative answer:
Server:  UnKnown
Address:  192.168.1.1

Name:leapsecond.utcd.org
Address:  244.34.36.97

Win10 64-bit

C:\Users\Andy>nslookup leapsecond.utcd.org
Server:  UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:leapsecond.utcd.org
Address:  244.34.36.97

However,  tracert and ping  yield this on both W7 & W10:

$ tracert leapsecond.utcd.org
Unable to resolve target system name leapsecond.utcd.org.

$ tracert 244.34.36.97

Tracing route to 244.34.36.97 over a maximum of 30 hops

  1  Transmit error: code 1231.

Trace complete.

$ ping 244.34.36.97

Pinging 244.34.36.97 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.

Ping statistics for 244.34.36.97:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Weird!





--
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: Problem with named pipes

2016-01-08 Thread Corinna Vinschen 
On Dec 25 16:39, Ken Brown wrote:
> I've noticed a difference between Cygwin and Linux involving named pipes.  I
> don't know if this a bug or simply a difference.
> 
> Consider the following two scripts:
> 
> $ cat fifo1.sh
> #!/bin/sh
> set -x
> rm -f foo
> mkfifo foo
> exec 7>foo
> echo blah > foo
> 
> $ cat fifo2.sh
> #!/bin/sh
> set -x
> read bar < foo
> echo $bar
> 
> I run fifo1.sh in Terminal 1 and get the following on both Cygwin and Linux:
> 
> [Terminal 1]
> $ ./fifo1.sh
> + rm -f foo
> + mkfifo foo
> + exec
> 
> The call to echo in the next line blocks, because foo has not yet been
> opened for reading.  Now I run fifo2.sh in Terminal 2.  On Linux, the "read"
> in fifo2.sh unblocks fifo1.sh, and I see the following:
> 
> [Terminal 1, Linux]
> $ ./fifo1.sh
> + rm -f foo
> + mkfifo foo
> + exec
> + echo blah
> 
> [Terminal 2, Linux]
> $ ./fifo2.sh
> + read bar
> + echo blah
> blah
> 
> On Cygwin, however, Terminal 1 remains blocked, and Terminal 2 is blocked
> when it tries to read:
> 
> [Terminal 2, Cygwin]
> $ ./fifo2.sh
> + read bar
> 
> The problem disappears if I remove the line "exec 7>foo" from fifo1.sh.  The
> problem also disappears if I leave that line in, but change the last line to
> "echo blah >&7".

Very tricky problem.  The FIFO code falls over its own feet trying to
handle more than one writer (exec 7> is the first, echo blah is the
second writer).  Sigh.  This code needs a thorough rewrite...


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature

Re: cygwin.dll: bug with select on Windows console

2016-01-08 Thread john hood 
On 1/8/16 11:29 AM, Corinna Vinschen wrote:
> On Jan  7 13:18, John Hood wrote:
>> Sorry about forgetting the testcase (which was good, actually, that
>> version had a bug).  I've attached it here.  This takes a single
>> argument, the timeout value for select() in microseconds.  A value of
>> 100 is fine for testing this issue.  Type at it, or just bang on the
>> keyboard with random keystrokes, and it will report the results from
>> select() and the characters read.  On a Windows console, it should
>> report an error within a few seconds.  Moving the mouse cursor over the
>> Windows console window while typing seems to provoke the error as well. 
> 
> No chance.  I tried this for a good hour now with the unpatched Cygwin
> DLL on 32 bit W7 and 64 bit W10 in 32 and 64 bit in a Windows console,
> and I can't provoke this error.  It just works for me.

My apologies for sending you down a wrong path.  Try again with
"socket-t 1000", which only waits 1ms.  I don't know what I was thinking
when I said the 1s timeout works fine.  I have 3 machines available; on
two the problem occurs within 1-2s of typing or mousing, and the last
might take a couple of minutes.  Don't spend too long trying to
reproduce this-- let me know and I'll try and figure out what other
variables might be at play.  One possibility is that my main Windows
machine is relatively slow.  It has an AMD E-350 CPU, which is
netbook-grade.  At one point I noticed that select() takes over 1ms to
execute, which affects its check for a timeout in the loop over
the ready check.  But then I saw that longer timeout values suffered the
problem as well, and the other two machines are faster Intel Core/Xeon
CPUs, Sandy Bridge or better.

>> On mintty or any other pty, the error never occurs.
>>
>> I've been unable to build Cygwin from Git on my 32-bit install on Win7,
>> thanks to various header mismatches and missing packages-- I think the
>> latest was a mingw-gcc header, but I can't check that machine now.  The
>> FAQ entry on how to build Cygwin is quite incomplete.  Are there any
>> better directions for building Cygwin?
> 
> What exactly is failing?  If you installed all the packages mentioned in
> the FAQ entry, plus building outside the source tree as outlined, you
> should be fine.  Alternatively, install the cygport package and the
> 2.4.0-0.16 source package and build that via

It appears I had not installed all the packages because I didn't have
the setup command line syntax right, and didn't know it.  setup
apparently does not do any validation of its command line arguments:

  setup-x86.exe -M -P "docbook-xsl xmlto"

fails to install any packages, and

  setup-x86.exe -M -P docbook-xsl xmlto

only installs the first.  Neither give any indication that the command
line is incorrect.

regards,

  --jh

--
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: cygwin.dll: bug with select on Windows console

2016-01-08 Thread Achim Gratz 
john hood writes:
> It appears I had not installed all the packages because I didn't have
> the setup command line syntax right, and didn't know it.  setup
> apparently does not do any validation of its command line arguments:
>
>   setup-x86.exe -M -P "docbook-xsl xmlto"
>
> fails to install any packages, and

Because there is no package "docbook-xsl xmlto".

>   setup-x86.exe -M -P docbook-xsl xmlto
>
> only installs the first.

Because non-option arguments are ignored when the command line is
processed as the corresponding handler is set to NULL and setup doesn't
check if there are any remaining arguments after option processing.
That could be changed, I guess.

> Neither give any indication that the command
> line is incorrect.

As far as setup is concerned, the command lines are correct.  To do what
you want, you can either comma-separate the package names behind a
single package option

   setup-x86.exe -M -P docbook-xsl,xmlto

or give one package per package option

   setup-x86.exe -M -P docbook-xsl -P xmlto

or even mix the two styles

   setup-x86.exe -M -P docbook-xsl,xmlto -P docbook-utils

HTH.


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

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

--
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: [PWNED/DOSSED] Cygwin's setup-x86.exe loads and executes rogue DLL from its application directory

2016-01-08 Thread Eric Blake 
[I got this mail via cc; I don't see the original in the mail archives,
which means it probably got eaten by the spam trap for too many raw
email addresses or other heuristics.  I don't maintain cygwin.com, so
I'm only commenting as a side observer here...]

On 01/07/2016 02:59 PM, Stefan Kanthak wrote:

>> If this was your original off-list post, you just violated your own
>> policy since you included cygwin AT cygwin.com which is a public list
>> on the ping, and thereby made the issue public, without waiting 45 days.
> 
> Simply wrong!
> Cygwin doesn't name a security mailbox on
> , 
> states
> 
> | cygwin: In general, you should send questions and bug reports here.
> 
> (which I did), and all of , 
> and  bounce: see
>  regarding this well-known role
> account (unfortunately RfC-ignorant.org closed).

Okay, maybe we should consider creating a closed-subscription
non-public-archives secur...@cygwin.com mailing list (however,
cygwin.org and sourceware.org are not the right domains).  Or at least
update the web page to mention secal...@redhat.com as a reasonable
alternative closed list to contact with potential Cygwin security flaws.
 I'll leave that up to others with actual admin rights on the cygwin.com
box, though.


> Next time: THINK BEFORE YOU POST!

Shouting at people is not the friendliest way to resolve security or
other issues.

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



signature.asc
Description: OpenPGP digital signature