Created attachment 512857 [details] gai.c program Description of problem: getaddrinfo for 127.0.0.1 (and I assume all IPv4 and IPv6 numeric address) will return EAI_NONAME if there are no connected network interfaces other than loopback. This will be the case on a Fedora 15 system using NetworkManager. Connections will come and go (for example WiFi, plug and unplug cables). The attached program is a cut down version of what httpd uses from the APR sockaddr.c when handling this VirtualHost line from httpd.conf: <VirtualHost 127.0.0.1:80 [::1]:80> Version-Release number of selected component (if applicable): # rpm -q glibc glibc-2.14-2.i686 How reproducible: Install Fedora 15 on a system with one wired ethernet, choosing the "Web server" option. Compile the attached program and copy to test system. gcc -g -std=gnu99 -o gai gai.c Steps to Reproduce: 1. Plug in cable to ethernet on a DHCPv4 enabled network 2. run ./gai - it will succeed 3. Unplug the cable from ethernet 4. run ./gai - it will fail Actual results: # ./gai getaddrinfo 1( 127.0.0.1, NULL, ... ) ai_family=2, ai_socktype=1, ai_flags=32 getaddrinfo 1 => EAI_NONAME(-2) error # Expected results: # ./gai getaddrinfo 1( 127.0.0.1, NULL, ... ) ai_family=2, ai_socktype=1, ai_flags=32 getaddrinfo 1 => Success(0) family: AF_INET sin_addr 0x0100007f sin_port 0x0000 # Additional info:
Created attachment 513595 [details] Fix getaddrinfo bug This patch fixes the problem by preventing getaddrinfo from confusing being connected and being able to provide address information.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This behavior is per rfc3493. In essence, when AI_ADDRCONFIG is specified an IPV4 address shall be returned if and only if an IPV4 address is configured on the local system excluding the loopback interface. There's similar language for IPV6 as well.
I'm afraid this is a bug because rfc3493 doesn't state that AI_ADDRCONFIG is default.
Sorry for the last comment, it's not default, at least not in Fedora. See the upstream bugs reports: http://sourceware.org/bugzilla/show_bug.cgi?id=12377 http://sourceware.org/bugzilla/show_bug.cgi?id=12398
Jeff, or maybe this could be marked as a dupe of 808147?
(In reply to comment #1) > Created attachment 513595 [details] > Fix getaddrinfo bug > > This patch fixes the problem by preventing getaddrinfo from confusing being > connected and being able to provide address information. I slightly favor my fix that removes the problematic code altogether. http://sourceware.org/bugzilla/attachment.cgi?id=6648
Pavel, The problem I see is that your patch will cause glibc to violate POSIX.1-2008 which states: If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned only if an IPv4 address is configured on the local system, [IP6] [Option Start] and IPv6 addresses shall be returned only if an IPv6 address is configured on the local system. [Option End] If glibc is going to make a decision to explicitly violate the POSIX standard, then that's a decision that needs to be made upstream. Discussing it here is pointless, particularly since I'm not an expert in this stuff. It must be discussed upstream. Or am I misunderstanding the net effect of your patch?
(In reply to comment #8) > Pavel, > > The problem I see is that your patch will cause glibc to violate > POSIX.1-2008 which states: > > If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be returned > only if an IPv4 address is configured on the local system, [IP6] [Option > Start] and IPv6 addresses shall be returned only if an IPv6 address is > configured on the local system. [Option End] If POSIX says exactly this, then it will *not* violate it on systems with ::1 and 127.0.0.1 addresses which are automatically created by the kernel. As on those systems, POSIX AI_ADDRCONFIG (which is distinct from current GLIBC AI_ADDRCONFIG) would be a noop (which is exactly what my patch does). > If glibc is going to make a decision to explicitly violate the POSIX > standard, then that's a decision that needs to be made upstream. Thanks for your opinion. > Discussing it here is pointless, I'm discussing it here because other resources point here and people are referring to exactly this bug report. That means I need to keep the information here up to date for them. > particularly since I'm not an expert in this stuff. That's ok for me. You can keep the bug report CLOSED UPSTREAM until it's either fixed upstream or there's a larger-scale discussion at Fedora. > It must be discussed upstream. It has been ignored both upstream and downstream for long time. Partially, maybe, because I didn't have time to write a proper patch. But you don't even know how you helped me. POSIX was not among my resources until now and I didn't know POSIX has yet another useless definition, distinct from RFC 3493. > Or am I misunderstanding the net effect of your patch? Yes, it's a hotfix that disables AI_ADDRCONFIG altogether like if it didn't exist at all. Even though you are not including it among Fedora patches, this bug report may be used as a source of information for other bugreports for Fedora, RHEL and even other distributions. Thank you for your patience, Pavel
http://pubs.opengroup.org/onlinepubs/9699919799/ The search for getaddrinfo to get the relevant hunk of the standard. The text above was a direct quote. Note that POSIX doesn't specify that loopback addresses are to be ignored. In all it's a mess. Unfortunately little discussion happens in upstream bugzilla, the right place is libc-alpha which is the upstream development list. The problem with discussing it in RH's bugzilla is the folks that will ultimately have to agree to the change are not part of the discussion. It may also be the case that we need to involve the "Austin Group" if we need further clarification of the standard (link-local handling comes to mind).
(In reply to comment #10) > http://pubs.opengroup.org/onlinepubs/9699919799/ > > The search for getaddrinfo to get the relevant hunk of the standard. The > text above was a direct quote. Note that POSIX doesn't specify that > loopback addresses are to be ignored. But then we can ignore the entire AI_ADDRCONFIG on hosts that *have* loopback addresses. > In all it's a mess. I agree. > Unfortunately little discussion happens in upstream bugzilla, the right > place is libc-alpha which is the upstream development list. > The problem with discussing it in RH's bugzilla is the folks that will > ultimately have to agree to the change are not part of the discussion. I'm also seeking help within the company to resolve this issue, as my name is not very well known in the GLIBC world. And most of Red Hatters are also Fedora users. > It may also be the case that we need to involve the "Austin Group" if we > need further clarification of the standard (link-local handling comes to > mind). We should try to persuade them to actually *fix* the standard. Or we should just remove the loopback device if it must be buggy by definition :).
Filtering of non-DNS addresses in getaddrinfo() has no real use and it only causes problems. There's no reason to filter over the mere existence of addresses. Filtering over global address existence may only be desirable for global address resolution, which is DNS. But that should be done by the DNS resolver that only asks for addresses that make sense and only accepts addresses that it asks for.
One more note: Being POSIX compliant here would be utterly useless but it would also be harmless. That means if the problem is the compliance itself, it is possible to create a patch that would retain POSIX compliance, would only break the informational RFC. But after all, it would behave exactly the same as the above patch on real systems.
So in your opinion would it be better to ignore AI_ADDRCONFIG, violating the RFC, but still adhering to POSIX? Note this will almost certainly result in some folks complaining about about getting "useless" results back from getaddrinfo (say for example, getting IPV4 addresses on an IPV6 only system). Have you run this by Tore? What was his opinion?
(In reply to comment #14) > So in your opinion would it be better to ignore AI_ADDRCONFIG, Yes. > violating the RFC, Yes, violating the newer information RFC. > but still adhering to POSIX? Yes, possibly. We can either ignore POSIX or adhere to POSIX. Afaik when ::1 and 127.0.0.1 are present, adhering or ignoring POSIX is the same, as it only applies to cases when you have *no* IPv4 or IPv6 address at all. Adhering to POSIX may help in very special cases when people turn off IPv6 entirely in broken network environments. Otherwise it's just a formality. > Note this will almost certainly result in > some folks complaining about about getting "useless" results back from > getaddrinfo (say for example, getting IPV4 addresses on an IPV6 only system). I don't expect people with IPv6 only systems to complain. And people with IPv4 only systems (but with IPv6 link-local) addresses are already recieving them. But yes, people from the second group can start complaining because they *learn* about it. Solution #3 is the way to go if we really need to eliminate unneeded DNS query results. > Have you run this by Tore? What was his opinion? Tore confirmed the current status of: https://fedoraproject.org/wiki/Networking/NameResolution#Flag_AI_ADDRCONFIG_considered_harmful Including solution #3 and fallback to solution #1 until #3 is implemented. Solution #2 (keep the behavior, remove AI_ADDRCONFIG from all applications) has also its proponents. But I personally think that: 1) It's too much work across a huge number of packages. 2) I think that applications could keep setting AI_ADDRCONFIG and later benefit from solution #3, if it's ever implemented.
(In reply to comment #15) > > Note this will almost certainly result in > > some folks complaining about about getting "useless" results back from > > getaddrinfo (say for example, getting IPV4 addresses on an IPV6 only system). > > I don't expect people with IPv6 only systems to complain. And people with > IPv4 > only systems (but with IPv6 link-local) addresses are already recieving them. > > But yes, people from the second group can start complaining because they > *learn* about it. Solution #3 is the way to go if we really need to eliminate > unneeded DNS query results. > > > Have you run this by Tore? What was his opinion? > > Tore confirmed the current status of: > > https://fedoraproject.org/wiki/Networking/ > NameResolution#Flag_AI_ADDRCONFIG_considered_harmful > > Including solution #3 and fallback to solution #1 until #3 is implemented. #1 would solve unexpected failures when resolving stuff like "localhost", "::1", "127.0.0.1", etc. But it will not fix the problem that I've been wanting to see fixed, namely that AI_ADDRCONFIG doesn't suppress IN AAAA DNS queries on systems with only link-local and loopback IPv6 addresses. It would actually aggravate that problem, as IN AAAA queries would no longer be suppressed om a machine without link-local and loopback IPv6 addresses as well. It will also introduce a new problem, as IN A queries would no longer be suppressed on IPv6-only systems. I don't know if this is problematic, and if so to what extent. But I wouldn't call it a "solution" - as what we'd be doing, essentially, is to exchange some bugs for some new ones. However, if we go down the #1 path, we might as well properly deprecate AI_ADDRCONFIG (change manual pages, emit warnings when applications are using it etc.). My personal favourite would be solution #3, plus reinstating the behaviour of ignoring IPv6 link-locals. I believe that one would solve all the problem cases, and introduce no new issues. #3 is also, as far as I can tell, in line with how Mac OS X and Microsoft Windows has implemented it. If #3 is where we want to go, I don't really see understand why do a "pit stop" at #1. Tore
I replied in good faith that you confirmed the information I provided. (In reply to comment #17) > It would actually aggravate that > problem, as IN AAAA queries would no longer be suppressed om a machine > without link-local and loopback IPv6 addresses as well. That's what would be solved by adhering to POSIX, afaik, see information in my comment above. But I wouldn't call it a 'problem'. > It will also introduce a new problem, as IN A queries would no longer be > suppressed on IPv6-only systems. I agree except I wouldn't use a word 'problem'. Problem is what we have now, things that should resolve won't resolve. Sending unnecessary A queries is also not a problem, just slight inefficiency. > I don't know if this is problematic, and if so to what extent. If defunct AI_ADDRCONFIG in the most proficient use case was not a problem, why should it be in use cases that never needed it. > But I wouldn't call it a "solution" It is a solution, as it solves the real and grave problems. > - as what we'd be doing, essentially, is to exchange some bugs for some new ones. We are solving bugs that make things actually broken. I agree, that the next step would be to fix inefficiencies. > However, if we go down the #1 path, we > might as well properly deprecate AI_ADDRCONFIG (change manual pages, emit > warnings when applications are using it etc.). That's solution #2. I thought you wanted to make use of AI_ADDRCONFIG. But if you agree that we don't need it, then I conclude that we could actually just do #1 and #2 and drop AI_ADDRCONFIG support entirely (ignore it forever). But I thought you regard AI_ADDRCONFIG as potentially useful if fixed as in #3. > My personal favourite would be solution #3, I'm afraid you confuse the situation a bit. If you favour solution #3, that we don't want to do #2. And if we can't do #3 quickly, we should do #1 first (to fix the real problems) and then do #3 to make AI_ADDRCONFIG useful. Which is what I proposed. Keeping POSIX compatibility is mostly just a formality except the very case of a system without IPv6 support. > plus reinstating the behaviour of ignoring IPv6 link-locals. Yes. But if you do that in getaddrinfo() proper, you will break more stuff. That means it should be done *when* #3 is implemented, and it should be done in the DNS plugin. > I believe that one would solve all the problem cases, and introduce no new issues. Yes. But nobody's working on it afaik, and #1 is a good short-term solution that doesn't introduce real problems, just inefficiency. DNS servers in the wild that can't handle IPv4 are purely imaginary. > #3 is also, as far as I can tell, in line with how Mac OS X and Microsoft Windows has implemented it. Could you please provide some sources. Information from other people contradicts it. I even had a link to some manuals that also contradicted this but I can't find it right now. But it would make sense, as it would be according to the previous RFC. We could then issue errata for the RFC and also submit it for POSIX. > If #3 is where we want to go, I don't really see understand why do a "pit stop" at #1. Because we want to have a working system. And because we have a patch for #1 and nobody even announced he's working on #3. And also because #1 is effectively a prerequisite for #3, as it removes the processing where it doesn't belong and #3 puts it where it does. I don't understand why we need to keep our systems broken for such a long time. I'm already using the patch for myself, to avoid the real bugs. And yes, it feels much better to have that patch, that to workaround by manually setting imaginary IP addresses to fool broken getaddrinfo().
Okay, let me try to clarify my position a bit. First, I think that AI_ADDRCONFIG's IN A/AAAA query suppression feature is useful. The way I see it, this is the primary reason for AI_ADDRCONFIG's existence in the first place. It reduces unecessary network traffic, query load on the resolvers, may in some cases speed up getaddrinfo() overall as it only has to wait for one answer to come back before returning, and may avoid tickling bugs in resolvers on single-stacked networks. This works today, but there is a clear shortcoming when it comes to computers auto-configured with link-local addresses. I do not know if the getaddrinfo() result set filtering logic in itself is useful. In other words, I don't know whether it is in useful to suppress AF_INET6 results from getaddrinfo() on single-stack IPv4 machines (or vice versa) for queries that did not cause DNS lookups (e.g., /etc/hosts, nscd-cached results, and so on). I don't take the position that it is *not* useful either, I simply just do not know if any programmers are relying on this filtering to take place or not. But it does indeed cause some corner case behaviours that the users may find unintuitive (IP literals, localhost, etc.). Second, the current AI_ADDRCONFIG behaviour has been unchanged for a long time (disregarding my reverted patch). As far as I know, there have been no recent developements that increases the urgency of the issue. Therefore, I see no reason to rush to implement a patch that only solves one part of the issue, especially considering that it makes another part of the issue worse. I hope that clears up my position somewhat. Regarding the Mac OS X/Windows comment: When I developed the ignore-link-locals patch, I tested to see what those operating systems did in the relevant case (when there's IPv6 link-local and loopback addresses present, but no other IPv6 addreses), and they did suppress AAAA queries in that case. However, this was a couple of years ago now, and that there has been significant changes since then (Mac OS X implemented "Happy Eyeballs", Windows 8 was released), so I cannot guarantee that this is still the case.
(In reply to comment #18) > I replied in good faith that you confirmed the information I provided. On this point in particular, I'd like to clarify that what I agree to, is that https://fedoraproject.org/wiki/Networking/NameResolution#Flag_AI_ADDRCONFIG_considered_harmful contains a fair summary of the issues with the current implementation of AI_ADDRCONFIG. That should not be interpreted as me supporting all the three proposed solutions at the same time.
(In reply to comment #19) > Okay, let me try to clarify my position a bit. Thanks. > First, I think that AI_ADDRCONFIG's IN A/AAAA query suppression feature is > useful. The way I see it, this is the primary reason for AI_ADDRCONFIG's > existence in the first place. It reduces unecessary network traffic, query > load on the resolvers, may in some cases speed up getaddrinfo() overall as > it only has to wait for one answer to come back before returning, and may > avoid tickling bugs in resolvers on single-stacked networks. This works > today, but there is a clear shortcoming when it comes to computers > auto-configured with link-local addresses. Yes. This is unrelated to the filtering problem. > I do not know if the getaddrinfo() result set filtering logic in itself is > useful. In other words, I don't know whether it is in useful to suppress > AF_INET6 results from getaddrinfo() on single-stack IPv4 machines (or vice > versa) for queries that did not cause DNS lookups (e.g., /etc/hosts, > nscd-cached results, and so on). I take the position that it is *harmful*. And this is the reason why the bug reports have been filed and why users would benefit from #1. > I don't take the position that it is *not* > useful either, I simply just do not know if any programmers are relying on > this filtering to take place or not. They cannot, because it doesn't work. They actually *do* rely on many things that are plain wrong. This is why I started tracking getaddrinfo() bugs in packages. If they do rely on something that is already doesn't work, we'll have to fix that anyway. > But it does indeed cause some corner > case behaviours that the users may find unintuitive (IP literals, localhost, > etc.). It causes services to be unreachable. That is a serious bug, in my opinion. Many services rely on link-local networking and with the systemd transition, more an more of those services will start *before* networking is started. > Second, the current AI_ADDRCONFIG behaviour has been unchanged for a long > time (disregarding my reverted patch). As far as I know, there have been no > recent developements that increases the urgency of the issue. I disagree. Systemd integration and new ways to handle networking dependencies may make services start before network connection is acquired. Also, with IPv6 advancement, services listening on ::1 will be unavailabe on IPv4 hosts and services listening on 127.0.0.1 will be unavailable on IPv6 hosts. > Therefore, I > see no reason to rush to implement a patch that only solves one part of the > issue, especially considering that it makes another part of the issue worse. It solves the real world problems and doesn't make any other real world part of the issue worse, as you must already know. > I hope that clears up my position somewhat. Thank you. > Regarding the Mac OS X/Windows comment: When I developed the > ignore-link-locals patch, I tested to see what those operating systems did > in the relevant case (when there's IPv6 link-local and loopback addresses > present, but no other IPv6 addreses), and they did suppress AAAA queries in > that case. This is different from your previous statement. I'm afraid you are once again talking about DNS when the whole issue is *not* in DNS. > However, this was a couple of years ago now, and that there has > been significant changes since then (Mac OS X implemented "Happy Eyeballs", > Windows 8 was released), so I cannot guarantee that this is still the case. It doesn't matter since I wanted to confirm that they don't filter out *non-DNS* responses. And now you are talking about unrelated DNS queries.
Another problem is, that if we won't solve it in getaddrinfo(), I will be forced to present the issue to package maintainers and we will be removing AI_ADDRCONFIG one by one from critical software that has this problem. The other thing is that the real behavior of getaddrinfo() is nowhere documented and that the manual page describes a theoretical behavior that people tend to believe is what getaddrinfo() actually does.
(In reply to comment #21) > > First, I think that AI_ADDRCONFIG's IN A/AAAA query suppression feature is > > useful. The way I see it, this is the primary reason for AI_ADDRCONFIG's > > existence in the first place. It reduces unecessary network traffic, query > > load on the resolvers, may in some cases speed up getaddrinfo() overall as > > it only has to wait for one answer to come back before returning, and may > > avoid tickling bugs in resolvers on single-stacked networks. This works > > today, but there is a clear shortcoming when it comes to computers > > auto-configured with link-local addresses. > > Yes. This is unrelated to the filtering problem. That may be true, but the proposed solution #1 does impact this IN A/IN AAAA filtering in a very negative way. Unless I've misunderstood something fundamental, #1 will disable it completely. > > I do not know if the getaddrinfo() result set filtering logic in itself is > > useful. In other words, I don't know whether it is in useful to suppress > > AF_INET6 results from getaddrinfo() on single-stack IPv4 machines (or vice > > versa) for queries that did not cause DNS lookups (e.g., /etc/hosts, > > nscd-cached results, and so on). > > I take the position that it is *harmful*. And this is the reason why the bug > reports have been filed and why users would benefit from #1. I don't really disagree with that. Just saying I can't know for sure that changing getaddrinfo() in this way won't tickle any hidden bugs in some applications that rely on the current behaviour. But I guess the solution to that would be to simply fix those applications. > It causes services to be unreachable. That is a serious bug, in my opinion. > > Many services rely on link-local networking and with the systemd transition, > more an more of those services will start *before* networking is started. Okay. I'd say it's really a bug in those services to be using AI_ADDRCONFIG in the first place, though. At least I don't think system services is what it's meant to be used for, but rather client applications such as web browsers and the like. The way I understand it, if an application is using AI_ADDRCONFIG on a node with no network connectivity, it should actually expect to get *no* results whatsoever. Do you have any bug ids for any of these problems, by the way? > It solves the real world problems and doesn't make any other real world part > of the issue worse, as you must already know. [...] > I'm afraid you are once again talking about DNS when the whole issue is > *not* in DNS. [...] > It doesn't matter since I wanted to confirm that they don't filter out > *non-DNS* responses. And now you are talking about unrelated DNS queries. Well then, please explain to me how the proposed solution #1 will not impact the DNS aspect of AI_ADDRCONFIG (i.e., the conditional IN A/IN AAAA DNS query suppression). If that indeed is the case, I'll be more than happy to shut up about DNS.
(In reply to comment #23) > (In reply to comment #21) > > > First, I think that AI_ADDRCONFIG's IN A/AAAA query suppression feature is > > > useful. The way I see it, this is the primary reason for AI_ADDRCONFIG's > > > existence in the first place. It reduces unecessary network traffic, query > > > load on the resolvers, may in some cases speed up getaddrinfo() overall as > > > it only has to wait for one answer to come back before returning, and may > > > avoid tickling bugs in resolvers on single-stacked networks. This works > > > today, but there is a clear shortcoming when it comes to computers > > > auto-configured with link-local addresses. > > > > Yes. This is unrelated to the filtering problem. > > That may be true, but the proposed solution #1 does impact this IN A/IN AAAA > filtering in a very negative way. Unless I've misunderstood something > fundamental, #1 will disable it completely. In the current systems, it's already disabled. > > > I do not know if the getaddrinfo() result set filtering logic in itself is > > > useful. In other words, I don't know whether it is in useful to suppress > > > AF_INET6 results from getaddrinfo() on single-stack IPv4 machines (or vice > > > versa) for queries that did not cause DNS lookups (e.g., /etc/hosts, > > > nscd-cached results, and so on). > > > > I take the position that it is *harmful*. And this is the reason why the bug > > reports have been filed and why users would benefit from #1. > > I don't really disagree with that. Just saying I can't know for sure that > changing getaddrinfo() in this way won't tickle any hidden bugs in some > applications that rely on the current behaviour. We are not changing its behavior in most environments. Unless you avoid the IPv6 module or something like that, you cannot see any difference from the current behavior. > But I guess the solution to > that would be to simply fix those applications. Sure, if anyone tests them with IPv6 disabled in kernel or something like that at all. > > It causes services to be unreachable. That is a serious bug, in my opinion. > > > > Many services rely on link-local networking and with the systemd transition, > > more an more of those services will start *before* networking is started. > > Okay. I'd say it's really a bug in those services to be using AI_ADDRCONFIG > in the first place, though. I think that the name resolution should be universal. One proccess can trigger another process and the latter process doesn't know that it's working in a special environment where it's normal processing won't work. > At least I don't think system services is what > it's meant to be used for, but rather client applications such as web > browsers and the like. As above, such services may call a command with "localhost" as one of its arguments. But next time the command will be called with a global DNS name. > The way I understand it, if an application is using > AI_ADDRCONFIG on a node with no network connectivity, it should actually > expect to get *no* results whatsoever. And that's wrong for the same reason. The same applications that you want to benefit from AI_ADDRCONFIG, are sometimes used to connect to localhost. In my opinion, either AI_ADDRCONFIG is important to be used, and then it must work with localhost and link-local addresses. Or AI_ADDRCONFIG shouldn't be used and neutralizing it is a logical step. If the application actually needs to first look at the list of IP addresses to decide whether to use AI_ADDRCONFIG or not, it could just as well set the ai_family accordingly and it would work much better > Do you have any bug ids for any of these problems, by the way? Most of them are RHEL bugs, but I started a tracker bug for Fedora, but there are no bug reports attached yet. But if you subscribe, you can get them when they are added. https://bugzilla.redhat.com/show_bug.cgi?id=883152 > > It solves the real world problems and doesn't make any other real world part > > of the issue worse, as you must already know. > [...] > > I'm afraid you are once again talking about DNS when the whole issue is > > *not* in DNS. > [...] > > It doesn't matter since I wanted to confirm that they don't filter out > > *non-DNS* responses. And now you are talking about unrelated DNS queries. > > Well then, please explain to me how the proposed solution #1 will not impact > the DNS aspect of AI_ADDRCONFIG (i.e., the conditional IN A/IN AAAA DNS > query suppression). If that indeed is the case, I'll be more than happy to > shut up about DNS. I didn't say it will not impact. But it is easy to show that in 99% of cases it actually won't. In most cases, you are using an IPv4 address on a wired or wireless ethernet. Unless you made something ugly to your system, that means you have a link-local address. And that means a non-loopback IPv6 address is present. And that means DNS lookups will *not be affected*. We can talk about PPP links and other stuff, but tell me how many linux devices you have, that you *never* use with a wired or wireless ethernet connection and therefore are not tested with AI_ADDRCONFIG behavior disabled. That said, AI_ADDRCONFIG's positive effects are just optimizations of linux PPP links and similar, otherwise they are absent (ethernet, wifi). If there are real issues with DNS servers, there are already in effect, unless your link-local IPv6 patch is in use.
(In reply to comment #24) > > That may be true, but the proposed solution #1 does impact this IN A/IN AAAA > > filtering in a very negative way. Unless I've misunderstood something > > fundamental, #1 will disable it completely. > > In the current systems, it's already disabled. Uh, no? It works just as it is supposed to. The specification does indeed have an oversight/shortcoming when it comes to IPv6 link-locals, reducing AI_ADDRCONFIG's utility that specific case, but in other cases, it works fine. > We are not changing its behavior in most environments. Unless you avoid the > IPv6 module or something like that, you cannot see any difference from the > current behavior. Try on an IPv4-only machine with no active Ethernet interfaces, or an IPv6-only machine. You'll see a difference, without having to resort to manual hackery. > In my opinion, either AI_ADDRCONFIG is important to be used, and then it > must work with localhost and link-local addresses. There's a reason why AI_ADDRCONFIG was specified in the first place, and there must be a reason why applications developers are actually using it (it's not the default behaviour). So, we should support it just as well as any other libc interface. Agreed that the localhost/link-local cases should be improved. > Or AI_ADDRCONFIG shouldn't be used and neutralizing it is a logical step. Perhaps. But silently disabling it is, in my opinion, the wrong thing to do. If you want to go down this path, the proper approach would be to fully deprecate it, and make sure the developers that are actually using it gets told that it won't work anymore and that they should stop using it. For example by making the compiler emit warnings when it sees it. > If the application actually needs to first look at the list of IP addresses > to decide whether to use AI_ADDRCONFIG or not, it could just as well set the > ai_family accordingly and it would work much better Agreed. The solution to that, however, is to selectively disable AI_ADDRCONFIG for those specific cases where we all agree it makes no sense (IP literals, loopback hosts, etc.). If you look at what Mozilla did, for example: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c5d74bcd7421 They do use AI_ADDRCONFIG, but they do specifically exclude "localhost" and some similar hostnames. Other browsers I've tested also suppress unneccesary DNS queries when on single-stacked networks. This tells me that the core AI_ADDRCONFIG functionality is actually wanted by the application developers. > We can talk about PPP links and other stuff, but tell me how many linux > devices you have, that you *never* use with a wired or wireless ethernet > connection and therefore are not tested with AI_ADDRCONFIG behavior disabled. *never*? Zero. Don't see how that is relevant, though. I've never claimed that disabling AI_ADDRCONFIG will make applications stop working. That doesn't mean it's a good idea. I mean, you could say the same thing about disabling SMP support in the kernel. Applications would still work, but desired functionality is lost. The applications on my laptop are making successful use of AI_ADDRCONFIG whenever I'm on the move and using mobile broadband for connectivity. This works, it's the desired behaviour, and there's no reason to break it. > That said, AI_ADDRCONFIG's positive effects are just optimizations of linux > PPP links and similar, otherwise they are absent (ethernet, wifi). If there > are real issues with DNS servers, there are already in effect, unless your > link-local IPv6 patch is in use. It's worth noting that AI_ADDRCONFIG isn't a Linux-specific interface. Applications are using it in a cross platform manner too, and they want it to actually work. That is not to say that glibc's implementation of AI_ADDRCONFIG doesn't have its shortcomings. We're in full agreement on that, I think. But I disagree strongly that ripping it out completely is the right way to handle that. I mean, if you go to the doctor with a broken finger you wouldn't expect him to amputate your entire arm. So IMHO we should fix the actual specific problems with glibc's AI_ADDRCONFIG, not remove it completely - and solution #3 seems to me to be the way to do that. If #3 is too difficult to implement in the short term, I'd rather like to see patch #1 modified so that it conditionally disables AI_ADDCONFING within getaddrinfo() if, and only if, getaddrinfo() is working on 1) the hostname "localhost" or one of its cousins, or 2) a literal IPv4 or IPv6 address.
Tore, I'm sorry not to reply to all individual cases. You fail to provide proper references. You fail to define thinks like 'the original purpose', 'the specification', 'the definition', and so on. You fail to see that localhost networking is very important. You even state that AI_ADDRCONFIG behaves as expected, while you fail to define what's expected because that what the glibc code does, is far from what anyone else would expect, and is far from all specifications that are out there. Overall, I'm very sorry to say that, you are *not* being helpful. You are even constructing awkward similes, that don't prove your point, nor bring new ideas to the discussion, like that one with the doctor. When I asked you to review my documentation at Fedora Wiki, you said that it's good. Except a small wording improvement, I got no suggestions through mail or IRC, I see no edits of the wiki page. Commenting wars in bugzilla about who is right and who is not, totally miss the point. So please stop fighting and start cooperating with me. Short time ago you were really helpful and our communication worked for a while. I have the following objectives: 1) Identify the problem with localhost and link-local addresses Done. It's in getaddrinfo() and AI_ADDRCONFIG flag. 2) Explore getaddrinfo() behavior under various system conditions Done. Several times. I must admit I failed to present the results in a detailed way. That's my fault. I will fix that ASAP. 3) Find possible solution I found three. One of them with your help. It's possible to find more. Are you going to propose any other possible solutions? 4) Choose a solution From those found at #3. Choose multiple solutions if some of them is not available in the near future and agree on a plan. 5) Patch the software At least with a quick fix. 6) Submit ERRATA and/or comments to all respective standardization organizations This includes POSIX and IETF RFC. 7) Evaluate the solution and comments from standards organizations 8) Finalize the whole process and get be done with it Are there any points you disagree with in principle or would you like to add anything?
Almost missed the end of your comment... (In reply to comment #26) > If #3 is too difficult to implement in the short term, I'd rather like to > see patch #1 modified so that it conditionally disables AI_ADDCONFING within > getaddrinfo() if, and only if, getaddrinfo() is working on 1) the hostname > "localhost" or one of its cousins, or 2) a literal IPv4 or IPv6 address. This is impossible, as any name can be put in /etc/hostname and can serve as the local host name. And it also won't work for link-local addressing that I guess you would like to see fixed, too. But it's perfectly possible to make a quick fix that would only affect the gethostbyname* function choice. I don't think it is so important, as we're talking about improvement for non-ethernet usage only. It wouldn't be too difficult.
Added solution #1b: https://fedoraproject.org/wiki/Networking/NameResolution#Conclusion
(In reply to comment #27) > 2) Explore getaddrinfo() behavior under various system conditions > > Done. Several times. I must admit I failed to present the results in a > detailed way. That's my fault. I will fix that ASAP. Detailed description of current getaddrinfo() behavior under various system conditions is described here: https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG#Tests (I split the AI_ADDRCONFIG article out of the NameResolution article because if its increasing size.) (In reply to comment #26) > Uh, no? It works just as it is supposed to. This is not even good as a joke. If you look at the tests, you can see that: 1) In 1 of 6 tests getaddrinfo() does not even do what its manpage says. It's still better than I thought. 2) In 4 of 6 tests getaddrinfo() breaks some address literals (in all cases in accordance with the docs). In the other 2 cases it behaves as if AI_ADDRCONFIG was absent. 3) In 1 of 6 tests getaddrinfo() sends „unnecessary“ AAAA query (no tcpdump, just that I see the IPv6 address among the results). And it is the most common case (IPv4 on wired/wireless ethernet), so the 1 is much bigger here :). Note: I only posted tests for day-to-day use cases, *no* corner cases. IPv6-only connectivity being the most exotic one.
I cleaned up the whole wiki page: https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG I believe the clean up was substantial enough that I can ask all interested people to read it again, from the beginning. For the lazy ones, I also cleaned up the solutions but kept the original numbers to avoid confusion: 1a) Remove all code that deals with AI_ADDRCONFIG, effectively disabling it in the general getaddrinfo() code. 1b) Modify the code to disable all the filtering while keeping the gethostbyname* function selection which in turn affects DNS queries. 2a) Remove AI_ADDRCONFIG in all software that uses it. Deprecate AI_ADDRCONFIG and prevent/reject modifications that add it to any software. Can be used together with #1a. 2b) Implement workarounds over AI_ADDRCONFIG in all software. 3) Implement getaddrinfo() in the name service switch (which is a good idea in itself). Implement AI_ADDRCONFIG in the DNS plugin. This must be used together with #1a, to bring any effect.
Hi Pavel, I'm sorry that you feel I'm not being helpful. That's not my intention at all, I simply do not like the look of solution #1a (on its own) since it will break what works of DNS query suppression today. I do think localhost networking should work better, but not at the expense of breaking the query suppression feature. That's all I've been trying to say, really. Anyway. Getting back to (hopefully) being contructive: I do like the look of your solution #1b. If I understand correctly, it's effectively the same thing as #3, only implemented in a different way. I've edited the Wiki page quite a bit now, to include some more information of DNS query suppression and the current problem with it (IPv6 link-locals' effect on it). I also rewrote the parts where you used first-person formulations ("I think blah...") so that it has a more objective and collaborative sound to it, rather looking like it reflects only the subjective opinions of one person. I hope you think that's okay, and that you think that my other modification and additions are sensible. When making the changes, I realised there may be a misunderstanding going on. I do not think that it is important at all to filter getaddinfo()'s result set *at all*, even for results that originated from DNS. The only thing I feel that is important to filter, is the *actual DNS queries*. In other words, if you for example have some sort of host caching in place (e.g., NSCD), and do on a single-stacked machine: 1) getaddrinfo("www.google.com", AF_UNSPEC); // resulting in both IN A and IN AAAA DNS queries, seeding the cache with both IPv4 and IPv6 results 2) getaddrinfo("www.google.com", AF_UNSPEC, AI_ADDRCONFIG); // does not result in any DNS queries because the results are already cached ...I would say perfectly okay for getaddrinfo() call #2 to return *both* IPv4 and IPv6 retults to the caller. When reading the Wiki page it occured to me that you might be under the impression that I feel that doing so wolud *not* be okay. Maybe this makes it easier to come up with a solution that makes us both happy? For example your #1b + my #4 (newly added)?
Created attachment 660514 [details] Proposed solution 1B (In reply to comment #28) > But it's perfectly possible to make a quick fix that would only affect the > gethostbyname* function choice. I don't think it is so important, as we're > talking about improvement for non-ethernet usage only. It wouldn't be too > difficult. Patch attached. It makes AI_ADDRCONFIG only apply to forward hostname lookups, so that "::1", "127.0.0.1", "fe80::1%eth0", and so on never fails, regardless of AI_ADDRCONFIG being set. Unfortunately however, it will still filter all name-based lookups, so for example "localhost" will continue to resolve to only "127.0.0.1" or only "::1" on single-stack machines. As far as I've been able to understand, information on whether or not AI_ADDRCONFIG was requested isn't available within _nss_dns_gethostbyname*(), so the filtering continues to apply for all the gethostbyname*() functions exported by all NSS modules. The patch also bundles the ignore-ipv6-link-locals patch from bug #492541. It seems to work fine for me and seems like a net improvement over the current situation, so I would have no problem with such a patch being merged.
(In reply to comment #32) > Hi Pavel, I'm sorry that you feel I'm not being helpful. That's not my > intention at all, I'm sure it wasn't. > I simply do not like the look of solution #1a (on its own) > since it will break what works of DNS query suppression today. Yes, it will break a small minority of cases to fix a IMO critical bug. > I do think > localhost networking should work better, but not at the expense of breaking > the query suppression feature. That's all I've been trying to say, really. OK. I confirm you can have such an opinion. My opinion is different. And if it's so important for you, we can try to achieve something both can agree with. > Anyway. Getting back to (hopefully) being contructive: > > I do like the look of your solution #1b. OK. I'll try to create a patch for that. > If I understand correctly, it's effectively the same thing as #3, Yes. Definitely from the behavioral point of view (and thus from your point of view). > only implemented in a different way. > > I've edited the Wiki page quite a bit now, Amazing work! Four eyes rule is fulfilled :). > to include some more information > of DNS query suppression and the current problem with it (IPv6 link-locals' > effect on it). I also rewrote the parts where you used first-person > formulations ("I think blah...") so that it has a more objective and > collaborative sound to it, Great. > rather looking like it reflects only the > subjective opinions of one person. I hope you think that's okay, and that > you think that my other modification and additions are sensible. I diffed the site and I found *nothing* I could oppose. > When making the changes, I realised there may be a misunderstanding going > on. I do not think that it is important at all to filter getaddinfo()'s > result set *at all*, even for results that originated from DNS. The only > thing I feel that is important to filter, is the *actual DNS queries*. Agreed. > In other words, if you for example have some sort of host caching in place > (e.g., NSCD), and do on a single-stacked machine: > > 1) getaddrinfo("www.google.com", AF_UNSPEC); // resulting in both IN A and > IN AAAA DNS queries, seeding the cache with both IPv4 and IPv6 results > 2) getaddrinfo("www.google.com", AF_UNSPEC, AI_ADDRCONFIG); // does not > result in any DNS queries because the results are already cached What would happen if you reverse the order? > ...I would say perfectly okay for getaddrinfo() call #2 to return *both* > IPv4 and IPv6 retults to the caller. When reading the Wiki page it occured > to me that you might be under the impression that I feel that doing so wolud > *not* be okay. Yes. I wasn't sure about it and neither would the reader. > Maybe this makes it easier to come up with a solution that makes us both > happy? For example your #1b + my #4 (newly added)? Yes. The #4 would have been there from the beginning if I was trying to solve all of the problems and not only the localhost one. Modified my conclusion to include #4.
(In reply to comment #33) > Patch attached. It makes AI_ADDRCONFIG only apply to forward hostname > lookups, so that "::1", "127.0.0.1", "fe80::1%eth0", and so on never fails, > regardless of AI_ADDRCONFIG being set. > > Unfortunately however, it will still filter all name-based lookups, so for > example "localhost" will continue to resolve to only "127.0.0.1" or only > "::1" on single-stack machines. As far as I've been able to understand, > information on whether or not AI_ADDRCONFIG was requested isn't available > within _nss_dns_gethostbyname*(), so the filtering continues to apply for > all the gethostbyname*() functions exported by all NSS modules. > > The patch also bundles the ignore-ipv6-link-locals patch from bug #492541. > > It seems to work fine for me and seems like a net improvement over the > current situation, so I would have no problem with such a patch being merged. I'm against merging because of the failed name resolution. Would you like to improve the patch to match it with solution #1b, or should I do that? I'm ok with either variant. Cheers, Pavel
(In reply to comment #35) > I'm against merging because of the failed name resolution. Would you like to > improve the patch to match it with solution #1b, or should I do that? I'm ok > with either variant. You go right ahead. :-) I think the patch is about as much as my coding skills allows me do...as I've said before, I'm really a networking guy, not a coder. If you're able to take the patch as a starting point and make something out of it that would not affect /etc/hosts lookups, then that would be fantastic. I'll be very happy to test anything better that you can come up with. (In reply to comment #34) > OK. I confirm you can have such an opinion. My opinion is different. And if > it's so important for you, we can try to achieve something both can agree > with. Great! And, just for the record, it's not that my own computers/network would have a problem per se if AI_ADDRCONFIG went away completely, but - many applications are actually using it. I mean, if no applications were using it, then we could disable it or deprecate it or whatever, nobody would care. But the only reason why we are actually experiencing problems are that the applications are actually using it. All the major browsers use it, amongst others. So then I'm trying to understand - why are they using it, what do they want to get out of it? I seriously doubt their intention is to make lookups of "127.0.0.1", "::1", "fe80::1%eth0", etc. arbitrarily fail on single-stacked machines. And I seriously doubt it's to make "localhost" resolve to only one address family either (case in point: Firefox explicitly disables AI_ADDRCONFIG for the "localhost" name). So what other functionality is there that would explain why the application developers are actively using AI_ADDRCONFIG? The *only* think I can think of, is DNS query suppression. And to me, that's a tell-tale sign that we should really not kill that feature, but if anything fix it so that it works even better than it does today. I believe it works better on other platforms already (i.e., they implement #4), and so IMHO we should really aim to bring the glibc implementation up to speed. > > In other words, if you for example have some sort of host caching in place > > (e.g., NSCD), and do on a single-stacked machine: > > > > 1) getaddrinfo("www.google.com", AF_UNSPEC); // resulting in both IN A and > > IN AAAA DNS queries, seeding the cache with both IPv4 and IPv6 results > > 2) getaddrinfo("www.google.com", AF_UNSPEC, AI_ADDRCONFIG); // does not > > result in any DNS queries because the results are already cached > > What would happen if you reverse the order? Then the second call should at least generate a DNS query for the non-cached record. Assuming IPv6-only machine, if after call #1 we know the AAAA record but not whether or not there's an A record, we need to fill in the blanks if the applications requests both. That said, I don't really know if NSCD caching works in this way, it was just a hypothetical example. The point was that I think that getaddrinfo() w/AI_ADDRCONFIG can very well return *all* available results, of *all* address families, *even results that originally came from DNS*, *if*, and *only if*, doing so does not result in actual DNS queries (of the "wrong" address family) being sent out to the network/upstream resolver.
(In reply to comment #36) > You go right ahead. :-) I think the patch is about as much as my coding > skills allows me do...as I've said before, I'm really a networking guy, not > a coder. If you're able to take the patch as a starting point and make > something out of it that would not affect /etc/hosts lookups, then that > would be fantastic. I'll be very happy to test anything better that you can > come up with. Thanks. Will do. > (In reply to comment #34) > > > OK. I confirm you can have such an opinion. My opinion is different. And if > > it's so important for you, we can try to achieve something both can agree > > with. > > Great! > > And, just for the record, it's not that my own computers/network would have > a problem per se if AI_ADDRCONFIG went away completely, but - many > applications are actually using it. I mean, if no applications were using > it, then we could disable it or deprecate it or whatever, nobody would care. I'd rather say they are trying to use it, as the results are not really amazing. > But the only reason why we are actually experiencing problems are that the > applications are actually using it. All the major browsers use it, amongst > others. So then I'm trying to understand - why are they using it, what do > they want to get out of it? I can't imagine. > I seriously doubt their intention is to make lookups of "127.0.0.1", "::1", > "fe80::1%eth0", etc. arbitrarily fail on single-stacked machines. And I > seriously doubt it's to make "localhost" resolve to only one address family > either (case in point: Firefox explicitly disables AI_ADDRCONFIG for the > "localhost" name). So what other functionality is there that would explain > why the application developers are actively using AI_ADDRCONFIG? The only thing i can think of is that they're using it because someone told them to do so. > The *only* think I can think of, is DNS query suppression. And to me, that's > a tell-tale sign that we should really not kill that feature, but if > anything fix it so that it works even better than it does today. I believe > it works better on other platforms already (i.e., they implement #4), I don't believe anything I don't see relevant test results for :). > and so IMHO we should really aim to bring the glibc implementation up to > speed. Possibly. > > > In other words, if you for example have some sort of host caching in place > > > (e.g., NSCD), and do on a single-stacked machine: > > > > > > 1) getaddrinfo("www.google.com", AF_UNSPEC); // resulting in both IN A and > > > IN AAAA DNS queries, seeding the cache with both IPv4 and IPv6 results > > > 2) getaddrinfo("www.google.com", AF_UNSPEC, AI_ADDRCONFIG); // does not > > > result in any DNS queries because the results are already cached > > > > What would happen if you reverse the order? > > Then the second call should at least generate a DNS query for the non-cached > record. Assuming IPv6-only machine, if after call #1 we know the AAAA record > but not whether or not there's an A record, we need to fill in the blanks if > the applications requests both. I don't even know how (and if) nscd gets into play when you call getaddrinfo(). > That said, I don't really know if NSCD caching works in this way, it was > just a hypothetical example. I'd say unbound or dnsmasq work much better here than nscd could even theoretically. > The point was that I think that getaddrinfo() > w/AI_ADDRCONFIG can very well return *all* available results, of *all* > address families, *even results that originally came from DNS*, *if*, and > *only if*, doing so does not result in actual DNS queries (of the "wrong" > address family) being sent out to the network/upstream resolver. I have no problem with anything that's not worse than solution #1. It's easy to imagine I have no problem with this, too.
Reopening as we are working on the solution.
Jeff: If you don't want to have unresolved bugs on your name, I can take it.
Fedora 15 is dead, moving to Fedora 17.
*** Bug 808147 has been marked as a duplicate of this bug. ***
Solution by Tore Anderson here: http://sourceware.org/bugzilla/attachment.cgi?id=6781&action=diff Upstream comment here: http://sourceware.org/bugzilla/show_bug.cgi?id=12398#c8 Note that it only fixes this specific bug report, not all getaddrinfo() problems. For the other problems, see: https://bugzilla.redhat.com/show_bug.cgi?id=887577 (new) https://bugzilla.redhat.com/show_bug.cgi?id=505105
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still not fixed upstream.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
This is being tracked upstream: https://bugzilla.redhat.com/show_bug.cgi?id=721350
(In reply to Florian Weimer from comment #52) > This is being tracked upstream: > https://bugzilla.redhat.com/show_bug.cgi?id=721350 afaik you meant this bug link? https://sourceware.org/bugzilla/show_bug.cgi?id=12398 HTH
(In reply to Sven Kieske from comment #53) > (In reply to Florian Weimer from comment #52) > > This is being tracked upstream: > > https://bugzilla.redhat.com/show_bug.cgi?id=721350 > > afaik you meant this bug link? > https://sourceware.org/bugzilla/show_bug.cgi?id=12398 Yes, sorry about that.