View Bug Activity | Format For Printing
On Nov 20 a change in nss/nss_files/files-hosts.c:LINE_PARSER was introduced to treat ::1 the same way as 127.0.0.1. A lot of Linux systems have 127.0.0.1 localhost ::1 localhost in their /etc/hosts (though most have ip6-localhost for ::1 instead). The new behavior appears not to be mandated by any standard nor does it seem as a particularily useful change. The trouble is that now gethostbyname() (gethostbyname2(), getaddrinfo(), ...) will return duplicate 127.0.0.1 records in h_addr_list[] and some applications do not explect duplicate entries in this array (e.g. OpenLDAP). The new behaviour does not seem to gain anything so the old behavior should be restored.
Of course it gains something, otherwise it would not have been added. And programs which don't handle multiple addresses are simply broken and must be fixed anyway. Stop defending broken code.
I'm not trying to defend broken code and application fix makes sense if this change brings benefits. However, even if I trust your judgement, you didn't explain the gain of the change in the changelog entry, commit message, in-code comment, or anywhere else I've searched. Can you please at least explain it in this bug entry?
Stop reopening bugs. Search the web if you want an explanation, I don't have anything handy and certainly have no interest in writing it up.
I have tried to search the web already and found nothing. If you want to close bugs as INVALID/WORKSFORME, please provide a proper explanation.
Strange, I never saw your name on my paycheck. Since if that's not the case you cannot order me around.
But you cannot order me either. The bug still exists. getaddrinfo() returns fabricated records for AF_INET localhost that aren't specified in /etc/hosts at all.
There is no bug. Stop reopening.
(In reply to comment #3) > Stop reopening bugs. Search the web if you want an explanation, I don't have > anything handy and certainly have no interest in writing it up. I've found no discussion of this change on any of the glibc mailing list archives, after searching through September-November 2006 on libc-announce, libc-hacker, libc-alpha, glibc-cvs, or glibc-bugs. I think it's fair to say that if you don't want people to keep asking stupid questions, a little more documentation of your rationale will help. The CVS log entry is useful, at least: Support IPv6-style addresses for IPv4 queries if they can be mapped. But your implementation violates RFC2553: http://www.ietf.org/rfc/rfc2553.txt Page 25: Also note that the IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4- compatible addresses, ... Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return false for "::" and "::1". I.e., the RFC specifically forbids the mapping of the IPV6 loopback address to IPv4. As far as I can see, the current glibc behavior here is a bug.
Treating the IPv6 loopback address this way violates RFC2553.
Stop reopening the bug. If you want explanations pay somebody.
i could have sworn glibc was an FSF/GNU project which meant open source. but apparently i'm mistaken. if you want anything out of glibc, you've got to pay for it. awesome!
If I understand well, and since firefox 3 gave me trouble with this, I reckon that the fix should go in firefox 3: When using the glibc resolver for a name resolution, firefox has to parse all the entries returned and look explicitely for the entries with the address family it wants to use (and being careful of IPv6 mapped IPv4 addresses!).
Created an attachment (id=2693) getaddrinfo fix for 2.6.1/2.7 >Of course it gains something, otherwise it would not have been added. And >programs which don't handle multiple addresses are simply broken and must be >fixed anyway. Stop defending broken code. Seems you haven't cheked the code lately. I'll give you real life example explaining why the mistake of thinking that all hostnames that resolve to ::1 also resolve to 127.0.0.1 is causing big problems to users. I have ldap hosts defined as: localldap.example.org ldap1.example.org ldap2.example.org As I'm using TLS I must use hostname instead of ip-number. File /etc/hosts contains following ::1 localhost localldap.example.org 127.0.0.1 localhost As ldap services contain important data it is protected by internal firewall. The firewall accepts connection to ldap port from ldap-master and ::1. The reason for using localhost with ldap is that ldap is started as early as possible in boot to provide user information. It is started before any network other then localhost. Now as glibc-implementation of getaddrinfo() was changed the first connection is done to 127.0.0.1. Firewall blocks this connection and after timeout of 15 seconds the connection is tried to ::1. At that time it succeeds. As you can see the program definately can support multiple addresses form getaddrinfo() and can hardly be considered buggy. As OSS camp often says: "talk is cheep, show the code". I have added a fix that I have verified to work under 2.6.1. The code in question is identical in 2.7.
Program that is specifically bound to "::1" can't be connected by calling "127.0.0.1". Check the attachement.
Stop reopening bugs. There is nothing which is going to change here until we have unified lookups.
(In reply to comment #10) > Stop reopening the bug. If you want explanations pay somebody. I don't need an explanation at this point, your position here clearly goes against established standards (RFC2553). There is no valid justification that you could give. At this point you just have to commit the fixes that have been provided for you.
Paid $1 via paypal. Trans ID 3H4989806A1962407 Please fix.
Dammit, stop opening the bug. It is obvious that you know *NOTHING* about the issue at hand. Otherwise you would have noticed that this code has been entirely rewritten in the current code. It uses a very different implementation which allows to handle this situation differently.
So is this a good representation of the GNU project's style of development, quality control, etc? I don't know if this has good PR effects for you. To an outsider, this looks like: - I bind to localhost, AF_INET6. Someone tries to contact me via a symbolic hostname "localhost" and fails because AF_INET is tried first. (What if both are bound by DIFFERENT programmes?) - I ask GNU libc for the contents of /etc/hosts, and it lies to me - This breaks an RFC, deliberately - without explanation - the author of the breakage admits "it's fixed in the current development version" yet claims it's no bug (nōn sequitur!) Nice style, too: break something, say "we fix it by rewriting the code soon anyway". Why did you then break it in a released(!) version in the first place? Does GNU libc not care about preserving compatibility at all?
FYI: A) This bug is has made it to reddit, your famous! and B) Everyone's gonna think Ulrich Drepper is an arse who refuses to actually explain why he broke something. Coming at this completely from outside with no knowledge of what is going on, it seems obvious ulrich has an attitude problem. As to why, I can only suppose that faced with the possibility that he made a mistake, he has chosen to defend to the end of time rather than accept and fix it. Anyways, best of luck resolving this.
Guys, Wait a minute. It is quite unfair to jump into a conversation like this and take sides without having the whole picture. Ulrich Drepper wrote several times that there's an explanation and it would require work to give it to us. Sometimes, programmers can be a bit gruff. Doesn't make them wrong :) This bug report's new-found fame is quite unfortunate but it looks like if Ulrich now takes a few minutes to educate us (and it looks like he will have to if he wishes to keep his sanity!), the whole situation can be easily defused.
http://www.ietf.org/rfc/rfc3056.txt RFC 3056 Connection of IPv6 Domains via IPv4 Clouds February 2001 In any case, any 6to4 traffic whose source or destination address embeds a V4ADDR which is not in the format of a global unicast address MUST be silently discarded by both encapsulators and decapsulators. Specifically, this means that IPv4 addresses defined in [RFC 1918], broadcast, subnet broadcast, multicast and loopback addresses are unacceptable.
Stop reopening.
Seems obvious to me.
Created an attachment (id=2816) test case for IN6_IS_ADDR_V4COMPAT This does not appear to violate any RFCs. Howard Chu claims that this behavior violates RFC 2553. First of all, "IPv4-compatible addresses" have been deprecated by RFC 4291, section 2.5.5.1. Even if it had not been, this is an incorrect assumption. "IPv4-compatible addresses" would have implied that you could send an IPv6 packet over the wire addressed to, say ::209.132.176.174, and a router would then encapsulate it in an IPv4 packet to 209.132.176.174. This has been superceded by the 6to4 dynamic tunneling scheme, which instead gives each IPv4 address a /48 in IPv6-space. But I digress. What RFC 2553 means by 'IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4-compatible addresses' is that a router may not encapsulate ::1 in an IPv4 packet to 0.0.0.1. This behavior does not happen, because a host will drop packets to ::1 if it did not come through the "lo" loopback interface. Even if this were to happen, it would be beyond the scope of libc; it would be a kernel IP stack issue instead. As for the macro behavior quoted from RFC 2553, I wrote some test code (see attachment), and I get: IN6_IS_ADDR_V4COMPAT( ::1 ) = false IN6_IS_ADDR_V4COMPAT( :: ) = false There is nothing in the RFCs that specifies how /etc/hosts should behave, since that is not something that belongs in a protocol specification. If glibc decides to have "::1 localhost" implicitly act as if you had also typed "127.0.0.1 localhost", then so be it. None of the function behavior that I have tested violates what is described in the RFCs. That is not to say that I don't find this behavior a bit odd. I would love to hear from Ulrich what problem this functionality was intended to fix, but I don't believe that this is in any way a violation of spec. It's just a bit different from the way soe people might interpret it. phelix, this has nothing whatsoever to do with 6to4 tunneling. 6to4 tunneling describes embedding IPv6 packets within IPv4 packets. In Linux, that is handled completely by the kernel, and all applications, including libc, know is that they are opening an IPv6 socket. The RFC that you quote is saying that an IPv6 packet within an IPv4 packet sent to, for example, 127.0.0.1 is invalid. For the record, I tested this against glibc 2.7 on Ubuntu hardy.
Stop reopening the bug. And this is also no discussion forum. Go somewhere else.
I concur, Ulrich. This bug has been discussed to death and only the trolls are reopening it. If anyone wishes to "me too" this bug, please open a new bug. Thanks.
Stop commenting.
(In reply to comment #28) > Stop commenting. This bug is resolved.
Please stop reopening for a while, SyGroup GmbH and Redhat are negotiating for a solution. Please invest your time into patches fixing the lookup code of affected applications instead.
(In reply to comment #31) > Please stop reopening for a while, SyGroup GmbH and Redhat are negotiating for a > solution. Please invest your time into patches fixing the lookup code of > affected applications instead. i THINK THIS IS A BUG?
Yes, but not in glibc. Please file the bug with the affected applications. If these are fixed, the issue will disappear all by itself. Thus, your time is better invested spotting the affected applications and fixing them. Now pass along please, there's nothing to see here.
So, if it has been "discussed to death" (or was that a troll?) could we get an explanation for what the problem with the original behaviour was? The only thing I can think of is if the hosts file had the ::1 entry before the 127. one, it could cause delays? Is that it?
Is this open source terrorism? "Pay us money or the bug stays!"
(In reply to comment #35) > Is this open source terrorism? "Pay us money or the bug stays!" Idiot. There is no bug. Don't reopen.
(In reply to comment #36) > (In reply to comment #35) > > Is this open source terrorism? "Pay us money or the bug stays!" > > Idiot. There is no bug. Don't reopen. Will you reopen it for.. one MEEEEEEEEELLION dollars?
There is nothing to reopen. Period.
(In reply to comment #38) > There is nothing to reopen. Period. Would you say that's your FINAL ANSWER?
Fine. Whatever. I'll revert it, assholes.
I love DrPepper!
Can all the random people finally stop spamming this bug with irrelevant stuff, pretty please? Ulrich implied in comment 18 that this the current code does not do this anymore; so please don't reopen the bug unless *you* verified that this issue still exists in *current* code. Thank you.
Petr, To be fair, you set this off by repeatedly reopening this issue like a naughty brat. Anyways, you guys may want to edit the CheckCanChangeField function in process_bug.cgi and add something like: if ($bugid eq 4980) { return 0; }
(In reply to comment #40) > Fine. Whatever. I'll revert it, assholes. > Wow, you are a bastard. I hope you die alone. :D
please refrain from adding garbage on top of garbage. regardless of the original garbage, adding more will gain nothing.
Fix your fucking shit. Do I need to come to your office and slap some sense into you?
This is not slashdot. :(
(In reply to comment #47) > This is not slashdot. :( No. But it is now on the home page of http://www.promotinglinux.com/
Hello!! I didn\'t test anything but Ulrich didn\'t convince me that it was working, so I\'m reopening the bug!
Someone really should lock this bug.
it doesnt work
Please provide detailed information why, in what version and how doesn't it work if you reopen the bug.
Just can't live with this being "closed". It breaks too much bugs and violates RFC2553. Please fix soon!
no info provided about exactly what is still broken