Re: [ITP] xclip 0.12
On Sep 29 22:47, rolandc wrote: xclip is included in the Debian distribution: http://packages.debian.org/stable/xclip http://zfire.free.fr/cygwin/xclip-0.12-1.tar.bz2 http://zfire.free.fr/cygwin/xclip-0.12-1-src.tar.bz2 setup.hint - category: X11 requires: libXmu6 libX11_6 sdesc: Command line clipboard grabber ldesc: xclip is a command line utility that is designed to run on any system with an X11 implementation. It provides an interface to X selections (the clipboard) from the command line. It can read data from standard in or a file and place it in an X selection for pasting into other X applications. xclip can also print an X selection to standard out, which can then be redirected to a file or another program. Packaging looks good. It would be nice if you could provide not only the setup.hint in plain text, but also as downloadable link to simplify uploading. I uploaded this package with a tweak to setup.hint. The ldesc string contains quotation marks - (the clipboard). I just removed them. Please fix that in your local copy of setup.hint. Please send an announcement to the cygwin-announce mailing list per the description in http://cygwin.com/setup.html#submitting. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] tftp-hpa 5.0
Dear Chuck! First of all, thanks for your detailed review, response and your suggestions! Am 01.10.2010 17:47, schrieb Charles Wilson: We'll need to coordinate the release of tftp-hpa Hmmm...now that I think about it, it would be really great if the package name(s) themselves were simply tftp-5.0-N tftp-server-5.0-N Users aren't going to CARE that the implementation/source came from the 'tftp-hpa' distribution. [...] setup.exe doesn't have any provision for specifying conflicts. So, we can only have one (current) package that provides any specific file (such as /bin/tftp.exe or /usr/sbin/tftpd.exe). Ic. I'm not that of a Cygwin expert so I just trust your opinion here. Changing the package accordingly is fine for me. (Keeping inetutils' tftp implementation was just a quick idea w/o thinking about the conflict resolving stuff). While I don't really have any issues with remap, I wonder why you dropped tcpwrappers? It adds no complexity to the build, and helps -- to a certain degree -- with some of the security issues endemic to the tftp protocol. (Especially as tftpd-hpa operates in such a way that you *can't* call it via the 'tcpd' utility in inetd.conf). Also, the whole *point* of obsoleting inetutil's version is because it is not capable of support IPv6 -- but tftp-hpa is. So, I really think you should enable IPv6. Now, that means a lot of new porting work, because there are ALWAYS issues with porting IPv6 networking to cygwin/win32...see the rsh package's patches (also, xinetd). Ic. Well, what I've proposed here was the result of an internal project where we just needed bare-bone IPv4 tftpd functionality in an isolated environment w/o security concerns. As I ended up in quite some compiling errors (and found some posts suggesting that those aren't that easy to fix), I simply tried disabling features until tftpd finally worked. Worked for me, you know. :-) And as I wasn't sure if the package would be accepted or taken care of at all, I also didn't want to invest that much upfront effort, but chose to document limitations instead... We can for sure try to re-enable and fix all these issues, but as for you, my time for these tasks is also quite limited and I can't promise quick results here... Now, as far as dropping privileges...that's a tricky one. First, your assumption that most people will run tftpd as a standalone service under cygrunsrv is probably false. I imagine most people will use a superserver (inetd or xinetd) instead. [...] Thanks for all the insights on this complicated topic! Now, IMO, you NEVER EVER EVER EVER want to run the tftp server as ANY privileged user at all: cygserver, Administrator, SYSTEM, ... [...] tftp is SO incredibly insecure it boggles the mind. Letting random *unauthenticated* users upload to your machine (or download), using the credentials of Administrator? Using client-specified paths? Not just no, but hell no. (Recall that cygwin doesn't *really* jail chrooted processes; they can always use win32 functions to break out). Hmmm, anyone running tftpd should know that (s)he should protect it from any productive network as it's insecure by design. In my eyes, putting tftpd behind an effective firewall is just the right answer here. Any effort spent to improve tftpd's security concept *if you don't trust his peers* will only raise the security bar from 10 to 12% IMHO. That's the reason why I didn't spend any effort on this yet and why I personally don't see this as a top-prio. That's, btw, also the reason why I decided not to provide a (postinstall) script which activates a Windows service. People who want to use this piece should really know what they're doing... We should probably take additional discussions offline, just to keep from annoying the list with ongoing development. Sure. I'll come back to you via private mail as soon as I had a detailed look on all your points... -- Gernot
Re: [ITP] tftp-hpa 5.0
On 10/4/2010 5:28 AM, Corinna Vinschen wrote:
On Oct 4 10:24, Gernot Hillier wrote:
Am 01.10.2010 17:47, schrieb Charles Wilson:
So, I really think you should enable IPv6. Now, that means a lot of
new porting work, because there are ALWAYS issues with porting IPv6
networking to cygwin/win32...see the rsh package's patches (also,
xinetd).
Chuck, for the dumb of us, can you please reiterate in a few words
what problems you're talking about? I'm kind of in trouble to think
of any Cygwin-specific IPv6 problem apart from some border cases.
I have at least two packages which I use IPv6 with, openssh and
syslog-ng, and I have no trouble with them.
It's not so much *cygwin*, as *windows*. If a socket is opened to
listen for both IPv4 and IPv6 packets, then *all* received packets will
appear as IPv6 ones -- IPv4 ones will show up wrapped as
::::71.15.23.51 or something.
So, if the app listens for both packet types, it really better support
IPv4-in-IPv6 addressing. Many of them don't.
This isn't really a cygwin bug, but an application bug exposed by how
windows, underneath cygwin, handles mixed-mode sockets.
Also, when iterating interfaces, windows returns *a lot* more than the
obvious ones (like, my simple laptop with wireless + wired returns about
a dozen...some are VPN tunneling devices, etc) and IIRC lists the IPv6
ones first. There was also some issue, the details of which escape me
right now, related to IPv6 localhost ::1 and 127.0.0.1. But the point
is, on a windows machine the application MUST be able to deal with
multi-homed interfacing. A lot of the older apps aren't.
We can for sure try to re-enable and fix all these issues, but as for
you, my time for these tasks is also quite limited and I can't promise
quick results here...
IMHO a new tftp only makes sense if it has some visible advantages
over the old one. Tcpwrappers, readline and IPv6 shouldn't be that
tricky.
Yes on the first two...we'll just have to see on IPv6. Maybe tftp-hpa
is maintained well enough upstream that we won't see the problems that
cropped up wrt inetutils.
But we're all volunteers here. If it's not a security related problem,
we're not asking for quick.
Yep.
Hmmm, anyone running tftpd should know that (s)he should protect it from
any productive network as it's insecure by design. In my eyes, putting
tftpd behind an effective firewall is just the right answer here. Any
effort spent to improve tftpd's security concept *if you don't trust his
peers* will only raise the security bar from 10 to 12% IMHO.
Nevertheless, running tftp with admin privileges is not a good idea.
Maybe you should at least try to seteuid to uid 501, the default uid
for the Guest user.
I was thinking of borrowing a page from openssh's privsep 'sshd' user,
and using a -config script to create a 'tftpd' user. I did some work
over the weekend, and the way I have it structured now, tftpd will
(a) try to setuid to 'tftpd' (after chrooting, if -s is specified)
(b) unless -u USERNAME, in which case it will setuid to that user
(c) but, if USERNAME specified as the argument to -u is 'root', then
it will act like inetd/xinetd, where 'root' is taken to mean
'whatever privileged user I'm actually running as now': e.g.
setuid (getuid())
Unlike 'regular' tftpd, you're supposed to initially launch tftpd-hpa as
a privileged user, so it can chroot if required. It then drops
privileges by changing all of its IDs.
If anything fails, tftpd logs the error and exits; it never attempts to
keep going without dropping privileges -- unless you told it to remain
in a privileged state via '-u root'.
I've also moved the missing arpa/tftp.h header from inetutils to this
package, and restructured the installation process to use the package's
INSTALLROOT support instead of configuring with ${D} in the --prefix
argument. It builds and creates the packages, but...
I just have to test it.
(I've done nothing with regards to IPv6, readline, or tcpwrappers yet).
The tftpd-config script also gives you a choice between installing tftpd
as a superserver client, OR as a standalone service (in which case, the
server needs to be installed to run as cyg_server, but have the -u tftpd
argument). On a virgin machine, this means that tftpd-config would need
to create both the cyg_server privileged user AND the tftpd unprivileged
user. It's very similar to ssh-host-config.
Anyway, once I've done that, I'll send|post the updated tarballs before
beginning to address IPv6 et al -- which might not happen for a week or two.
We should probably take additional discussions offline, just to keep
from annoying the list with ongoing development.
Sure. I'll come back to you via private mail as soon as I had a
detailed look on all your points...
I disagree. We already had a lot of discussion about porting packages
to the Cygwin distro on this list. It might be worth to keep it here,
unless the two of you want to share
Re: [ITP] tftp-hpa 5.0
On 10/4/2010 4:24 AM, Gernot Hillier wrote:
First of all, thanks for your detailed review, response and your
suggestions!
You're welcome.
Am 01.10.2010 17:47, schrieb Charles Wilson:
We'll need to coordinate the release of tftp-hpa
Hmmm...now that I think about it, it would be really great if the
package name(s) themselves were simply tftp-5.0-N tftp-server-5.0-N
Users aren't going to CARE that the implementation/source came from
the 'tftp-hpa' distribution.
Ic. I'm not that of a Cygwin expert so I just trust your opinion here.
Changing the package accordingly is fine for me. (Keeping inetutils'
tftp implementation was just a quick idea w/o thinking about the
conflict resolving stuff).
OK. My revised package does this.
So, I really think you should enable IPv6. Now, that means a lot of
new porting work, because there are ALWAYS issues with porting IPv6
networking to cygwin/win32...see the rsh package's patches (also,
xinetd).
Ic.
Well, what I've proposed here was the result of an internal project
where we just needed bare-bone IPv4 tftpd functionality in an isolated
environment w/o security concerns. As I ended up in quite some compiling
errors (and found some posts suggesting that those aren't that easy to
fix), I simply tried disabling features until tftpd finally worked.
Worked for me, you know. :-)
And that's great; obviously your internal team can continue to use what
you have, until the revised version comes along. In fact, it's great
that you have an in-place testing environment; we can easily make sure
that the revised versions don't break anything.
And as I wasn't sure if the package would be accepted or taken care of
at all, I also didn't want to invest that much upfront effort, but chose
to document limitations instead...
That makes sense. However, as we/I are *very* enthusiastic about
deleting inetutils' tftp in favor of tftp-hpa, now's the time to make
that investment.
We can for sure try to re-enable and fix all these issues, but as for
you, my time for these tasks is also quite limited and I can't promise
quick results here...
NP.
Now, as far as dropping privileges...that's a tricky one. First,
your assumption that most people will run tftpd as a standalone
service under cygrunsrv is probably false. I imagine most people will
use a superserver (inetd or xinetd) instead.
[...]
Thanks for all the insights on this complicated topic!
Acquired through PAINFUL experience :-{
Now, IMO, you NEVER EVER EVER EVER want to run the tftp server as
ANY privileged user at all: cygserver, Administrator, SYSTEM, ...
[...]
tftp is SO incredibly insecure it boggles the mind. Letting random
*unauthenticated* users upload to your machine (or download), using
the credentials of Administrator? Using client-specified paths? Not
just no, but hell no. (Recall that cygwin doesn't *really* jail
chrooted processes; they can always use win32 functions to break
out).
Hmmm, anyone running tftpd should know that (s)he should protect it from
any productive network as it's insecure by design. In my eyes, putting
tftpd behind an effective firewall is just the right answer here. Any
effort spent to improve tftpd's security concept *if you don't trust his
peers* will only raise the security bar from 10 to 12% IMHO.
True. Client IP's CAN be spoofed -- but cygwin's tcp wrappers operates
by default in PARANOID mode, so the attacker would also have to hijack
the local DNS server. Not impossible, but worth more than +2%
difficulty rating.
That's the reason why I didn't spend any effort on this yet and why I
personally don't see this as a top-prio.
Well, it should Just Work(tm); tcp_wrappers does all the heavy lifting.
We'll see.
That's, btw, also the reason why I decided not to provide a
(postinstall) script which activates a Windows service. People who want
to use this piece should really know what they're doing...
Well, that's true of most insecure services. However, tftp-hpa DOES
drop privileges (assuming we un-#ifdef-out that stuff), so it NEEDS an
unprivileged user to change to. Since windows doesn't have a default
'nobody' user (other than Guest, and often that account is disabled
entirely), we need a script to create one. Even if it doesn't install
the service.
The problem with NOT making the process relatively turnkey simple, is
that you will spend five times the effort multiply answering FAQs on the
mailing list...How do I... This way, your form letter response is:
0) Read the documentation
1) run tftp-config
2) run xinetd-config
3) edit /etc/xinetd.d/tftp
- disabled yes
+ disabled no
4) (re)start xinetd:
cygrunsrv -E xinetd
cygrunsrv -S xinetd
Cut-n-paste as needed...(and note, variations like 'use inetd instead'
or 'install tftpd as a standalone service' are not mentioned; save that
for the documentation that nobody will read.)
We should probably take additional discussions offline, just to keep
from
[RFU] serf-0.7.0-1
Please leave 0.3.1-1 as current and delete all previous versions. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0-devel/libserf0-devel-0.7.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0_1/libserf0_1-0.7.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0_1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/serf/serf-0.7.0-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/serf-0.7.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/setup.hint -- David Rothenberger daver...@acm.org
Re: [ITP] tftp-hpa 5.0
On Oct 4 11:10, Charles Wilson wrote: On 10/4/2010 5:28 AM, Corinna Vinschen wrote: On Oct 4 10:24, Gernot Hillier wrote: Am 01.10.2010 17:47, schrieb Charles Wilson: So, I really think you should enable IPv6. Now, that means a lot of new porting work, because there are ALWAYS issues with porting IPv6 networking to cygwin/win32...see the rsh package's patches (also, xinetd). Chuck, for the dumb of us, can you please reiterate in a few words what problems you're talking about? I'm kind of in trouble to think of any Cygwin-specific IPv6 problem apart from some border cases. I have at least two packages which I use IPv6 with, openssh and syslog-ng, and I have no trouble with them. It's not so much *cygwin*, as *windows*. If a socket is opened to listen for both IPv4 and IPv6 packets, then *all* received packets will appear as IPv6 ones -- IPv4 ones will show up wrapped as ::::71.15.23.51 or something. Which functions are you talking about? getpeername? accept? readfrom? getaddrinfo? All of them? If so, we could do something about that by massaging the returned addresses from V4-in-V6 into plain V4 addresses. Since the memory region used for V6 can easily contain a V4 address, we don't have to change any memory allocation or so, just tweak the content of the sockaddr structure. Well, except in case AI_V4MAPPED is specified in getaddrinfo... So, if the app listens for both packet types, it really better support IPv4-in-IPv6 addressing. Many of them don't. This isn't really a cygwin bug, but an application bug exposed by how windows, underneath cygwin, handles mixed-mode sockets. Also, when iterating interfaces, windows returns *a lot* more than the obvious ones (like, my simple laptop with wireless + wired returns about a dozen...some are VPN tunneling devices, etc) and IIRC lists the IPv6 ones first. There was also some issue, the details of which escape me right now, related to IPv6 localhost ::1 and 127.0.0.1. But the point is, on a windows machine the application MUST be able to deal with multi-homed interfacing. A lot of the older apps aren't. Well, that's not exactly just a Windows problem. Any interface can at any time return more than one V4 and more than one V6 address. Not only my Windows machines, but also my Linux machines typically have at least one V4 and two V6 addresses. A tool which doesn't grok this is just horribly broken. I guess the age of inetutils really shows... Nevertheless, running tftp with admin privileges is not a good idea. Maybe you should at least try to seteuid to uid 501, the default uid for the Guest user. I was thinking of borrowing a page from openssh's privsep 'sshd' user, and using a -config script to create a 'tftpd' user. I did some work over the weekend, and the way I have it structured now, tftpd will (a) try to setuid to 'tftpd' (after chrooting, if -s is specified) (b) unless -u USERNAME, in which case it will setuid to that user (c) but, if USERNAME specified as the argument to -u is 'root', then it will act like inetd/xinetd, where 'root' is taken to mean 'whatever privileged user I'm actually running as now': e.g. setuid (getuid()) Unlike 'regular' tftpd, you're supposed to initially launch tftpd-hpa as a privileged user, so it can chroot if required. It then drops privileges by changing all of its IDs. If anything fails, tftpd logs the error and exits; it never attempts to keep going without dropping privileges -- unless you told it to remain in a privileged state via '-u root'. Sounds good to me. Anyway, once I've done that, I'll send|post the updated tarballs before beginning to address IPv6 et al -- which might not happen for a week or two. Just to let you know, I'll be mostly unavailable for the next five weeks starting this weekend. If there's something required in terms of the aforementioned V4inV6 problem, the time to do something is either now or late in November. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] tftp-hpa 5.0
Hi there! Am 04.10.2010 17:24, schrieb Charles Wilson: Hmmm...now that I think about it, it would be really great if the package name(s) themselves were simply tftp-5.0-N tftp-server-5.0-N Users aren't going to CARE that the implementation/source came from the 'tftp-hpa' distribution. Ic. I'm not that of a Cygwin expert so I just trust your opinion here. Changing the package accordingly is fine for me. (Keeping inetutils' tftp implementation was just a quick idea w/o thinking about the conflict resolving stuff). OK. My revised package does this. Ok, so I'll wait for your update... And that's great; obviously your internal team can continue to use what you have, until the revised version comes along. In fact, it's great that you have an in-place testing environment; we can easily make sure that the revised versions don't break anything. ... and try to push it into our product's mainline which should be well possible in the next weeks. However, please note that we don't use IPv6 and have no testbed for this. That makes sense. However, as we/I are *very* enthusiastic about deleting inetutils' tftp in favor of tftp-hpa, now's the time to make that investment. :-) Let me know when I can help. That's the reason why I didn't spend any effort on this yet and why I personally don't see this as a top-prio. Well, it should Just Work(tm); tcp_wrappers does all the heavy lifting. We'll see. Yes, I'll have a look on it as soon as I receive your update. Well, that's true of most insecure services. However, tftp-hpa DOES drop privileges (assuming we un-#ifdef-out that stuff), so it NEEDS an unprivileged user to change to. Since windows doesn't have a default 'nobody' user (other than Guest, and often that account is disabled entirely), we need a script to create one. Even if it doesn't install the service. Convinced. -- Gernot
Re: [ITP] tftp-hpa 5.0
On 10/4/2010 12:02 PM, Corinna Vinschen wrote: On Oct 4 11:10, Charles Wilson wrote: It's not so much *cygwin*, as *windows*. If a socket is opened to listen for both IPv4 and IPv6 packets, then *all* received packets will appear as IPv6 ones -- IPv4 ones will show up wrapped as ::::71.15.23.51 or something. Which functions are you talking about? getpeername? accept? readfrom? getaddrinfo? All of them? I'm going by memory here...and I don't recall. :-( I'll have to review those threads. If so, we could do something about that by massaging the returned addresses from V4-in-V6 into plain V4 addresses. Since the memory region used for V6 can easily contain a V4 address, we don't have to change any memory allocation or so, just tweak the content of the sockaddr structure. Well, except in case AI_V4MAPPED is specified in getaddrinfo... Well, that's basically what happens already. Incoming V4 packets get turned into AI_V4MAPPED ones, always, IIRC -- when the socket was set for both V4 and V6. Properly written applications, which claim to support V6, should handle V4-in-V6 seamlessly. If they don't, then it's an application bug. If they can only deal with true IPv4 packages or full IPv6 packets...then they should open two sockets, one in V6-only mode on the V6 address, and one in V4-only mode on the V4 address -- and even then it would fail if some other router mapped an incoming IPv4 as V4-in-V6 before it ever gets to your computer! It's easier, really, to just FIX the application to fully support V6, including the V4 variations. Otherwise, it doesn't REALLY support V6, now does it? Well, that's not exactly just a Windows problem. Any interface can at any time return more than one V4 and more than one V6 address. Not only my Windows machines, but also my Linux machines typically have at least one V4 and two V6 addresses. A tool which doesn't grok this is just horribly broken. I guess the age of inetutils really shows... Bingo. I always say that inetutils doesn't support IPv6 but that's not entirely true. inetd kinda sorta does, but badly -- which is where I ran into all of these issue; the patch is...large. The regular servers like rshd etc don't seem to support IPv6 at all. That's the main reason I'm (slowly) trying to use more modern implementations of the regular servers, which DO support IPv6. Like tftp-hpa. I was thinking of borrowing a page from openssh's privsep 'sshd' user, and using a -config script to create a 'tftpd' user. ... If anything fails, tftpd logs the error and exits; it never attempts to keep going without dropping privileges -- unless you told it to remain in a privileged state via '-u root'. Sounds good to me. :-) Anyway, once I've done that, I'll send|post the updated tarballs before beginning to address IPv6 et al -- which might not happen for a week or two. Just to let you know, I'll be mostly unavailable for the next five weeks starting this weekend. If there's something required in terms of the aforementioned V4inV6 problem, the time to do something is either now or late in November. If there is an actual problem that requires cygwin changes (which I doubt) then Nov is soon enough. I don't think it's a good idea for cygwin to automatically unwrap v4-in-v6, because we have no (easy) way of knowing if the packet ACTUALLY arrived on the v6 interface because somebody ELSE wrapped it before it reached our ethernet port, or if Windows wrapped something that arrived on the v4 interface, and then presented it to cygwin AS IF it arrived on the V6 interface, as a V4-in-V6 packet. This unwrapping is an application-level decision, IMO. It just means applications with (poorly coded) IPv6 support need additional fixin' before it will work as expected on cygwin, in mixed-mode environments. You're right, tho, that this is /not/ a cygwin-specific problem; there are many multi-homed and mixed-mode unix systems... -- Chuck
Re: [ITP] tftp-hpa 5.0
On Oct 4 13:13, Charles Wilson wrote: On 10/4/2010 12:02 PM, Corinna Vinschen wrote: If so, we could do something about that by massaging the returned addresses from V4-in-V6 into plain V4 addresses. Since the memory region used for V6 can easily contain a V4 address, we don't have to change any memory allocation or so, just tweak the content of the sockaddr structure. Well, except in case AI_V4MAPPED is specified in getaddrinfo... Well, that's basically what happens already. Incoming V4 packets get turned into AI_V4MAPPED ones, always, IIRC -- when the socket was set for both V4 and V6. Erm... hang on. A socket is created for only one domain/address family, AF_INET, AF_UNIX, AF_INET6. There's no such thing as a socket supporting more than one address family or more than one socket type (stream/dgram). It's easier, really, to just FIX the application to fully support V6, including the V4 variations. Otherwise, it doesn't REALLY support V6, now does it? Sure, you're right. Just to let you know, I'll be mostly unavailable for the next five weeks starting this weekend. If there's something required in terms of the aforementioned V4inV6 problem, the time to do something is either now or late in November. If there is an actual problem that requires cygwin changes (which I doubt) then Nov is soon enough. I don't think it's a good idea for cygwin to automatically unwrap v4-in-v6, because we have no (easy) way of knowing if the packet ACTUALLY arrived on the v6 interface because somebody ELSE wrapped it before it reached our ethernet port, or if Windows wrapped something that arrived on the v4 interface, and then presented it to cygwin AS IF it arrived on the V6 interface, as a V4-in-V6 packet. This unwrapping is an application-level decision, IMO. It just means applications with (poorly coded) IPv6 support need additional fixin' before it will work as expected on cygwin, in mixed-mode environments. There's a difference between Linux and Windows, though, which affects the returned addresses from getaddrinfo, if the AI_V4MAPPED and AI_ALL flags are set. In this case Linux returns V6 and V4 addresses, both formatted in their real address family. Unless the given host has no V6 address, in which case the V4 addresses are returned as V4inV6 addresses. On Windows, AI_V4MAPPED | AI_ALL always returns the V4 addresses as V4inV6 addresses. I read the SUSv4 getaddrinfo man page, and from what I can tell both results should be ok: If the AI_V4MAPPED flag is specified along with an ai_family of AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses on finding no matching IPv6 addresses [...] If the AI_ALL flag is used with the AI_V4MAPPED flag, then getaddrinfo() shall return all matching IPv6 and IPv4 addresses. As you can see, the text does not specify that in the AI_V4MAPPED | AI_ALL case the IPv4 addresses should be returned in a given address family. This *could* be changed in Cygwin to follow the Linux behaviour. However, I have no idea if that affects your case, of course... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] serf-0.7.0-1
On Oct 4 08:51, David Rothenberger wrote: Please leave 0.3.1-1 as current and delete all previous versions. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0-devel/libserf0-devel-0.7.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0_1/libserf0_1-0.7.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf0_1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/serf/serf-0.7.0-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/serf-0.7.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/setup.hint Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
RFU: python-gdata-2.0.12-1
Please upload: --- wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.12-1.tar.bz2 \ http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.12-1-src.tar.bz2 --- Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
RFU: cppcheck-1.45-1
Please upload: --- wget -x -nH --cut-dirs=1 \ http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.45-1.tar.bz2 \ http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.45-1-src.tar.bz2 --- Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d
[RFU] libaprutil1-1.3.10-1
wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/aprutil1/aprutil1-1.3.10-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/aprutil1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-1.3.10-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-1.3.10-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-devel/libaprutil1-devel-1.3.10-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/setup.hint -- David Rothenberger daver...@acm.org
Re: RFU: python-gdata-2.0.12-1
On Mon, 2010-10-04 at 17:54 -0400, Chris Sutcliffe wrote: http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.12-1.tar.bz2 \ http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.12-1-src.tar.bz2 Uploaded. Yaakov
Re: RFU: cppcheck-1.45-1
On Mon, 2010-10-04 at 18:08 -0400, Chris Sutcliffe wrote: http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.45-1.tar.bz2 \ http://emergedesktop.org/cygwin/cppcheck/cppcheck-1.45-1-src.tar.bz2 Uploaded. Yaakov
Re: [RFU] libaprutil1-1.3.10-1
On Mon, 2010-10-04 at 16:35 -0700, David Rothenberger wrote: wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/aprutil1/aprutil1-1.3.10-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/aprutil1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-1.3.10-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-1.3.10-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-devel/libaprutil1-devel-1.3.10-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/setup.hint Uploaded. Yaakov
