In addition to the standard "192.168.1.1" format, there are numerous
legacy IPv4 address formats (such as "192.168.257",
"0xc0.0xa8.0x01.0x01", "0300.0250.0001.0001", "3232235777", and
"0xc0a80101"). However, none of these forms are ever used any more
except in phishing attempts. GLib wasn't supposed to be accepting
these addresses (neither g_hostname_is_ip_address() nor
g_inet_address_new_from_string() recognizes them), but getaddrinfo()
accepts them, and so the parts of gio that use getaddrinfo()
accidentally did accept those formats.
Fix GNetworkAddress and GResolver to reject these address formats.
https://bugzilla.gnome.org/show_bug.cgi?id=679957
It is possible that the upstream servers return something, but
we then filter all results because they are of the wrong type.
In that case the API and subsequent GTask calls expect a GError
to be set.
https://bugzilla.gnome.org/show_bug.cgi?id=696857
Since there is only one resolver implementation now, we can move the
resolver utility functions from gresolver.c into gthreadedresolver.c,
and remove the prototypes from gnetworkingprivate.h.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
We were passing the wrong destroy notify when returning the list of
records, so it would crash if it got called (ie, if you didn't call
g_resolver_lookup_records_finish()).
(Also fix s/targets/records/ throughout the records functions.)
* Add resolver functions for looking up DNS records of
various types. Currently implemented: MX, TXT, SOA, SRV, NS
* Return records as GVariant tuples.
* Make the GSrvTarget lookups a wrapper over this new
functionality.
* Rework the resolver test so that it has support for
looking up MX, NS, SOA, TXT records, and uses GOptionContext
https://bugzilla.gnome.org/show_bug.cgi?id=672944
In particular, remove the libasyncns import, which was only used by
GUnixResolver, which is only used when threads are not available.
Likewise remove GWin32Resolver, and the hacky broken non-threaded
parts of GIOScheduler.
https://bugzilla.gnome.org/show_bug.cgi?id=616754
In resolve_sync function in gthreadedresolver.c, if g_thread_pool_push
fails due to thread creation failure, we are just simply appending the
data to the queue of work to do. After the failure, we might wait
indefinitely in g_cond_wait. In case of g_thread_pool_push failure,
propagate the error so that this function does not blocks forever in
case of failure.
https://bugzilla.gnome.org/show_bug.cgi?id=651034
When you're using the threaded resolver and using a sync call
without a cancellable the resolve_sync forgot to unlock the
initial req->mutex lock, leading to a deadlock when unrefing
the request.
GResolver provides asynchronous (and synchronous-but-cancellable) APIs
for resolving hostnames, reverse-resolving IP addresses back to
hostnames, and resolving SRV records. Part of #548466.
