The scanning to find the end of a positional parameter designator in
GVariant text format (e.g. '%i') is currently broken in case the 'end'
pointer is not specified.
The scan is controlled by a somewhat complicated loop that needs to deal
properly with cases like (123, %(ii)) [where '%(ii)' is to be taken
together, but the final ')' not].
This loop missed the case where a format string passed to
g_variant_new_parsed() ended immediately after such a conversion, with a
nul character. In this case the 'end' pointer is NULL, so the only way
we can find the end is by scanning for nul in the string.
In case of g_variant_new_parsed() [which is what this code was designed
to be used for], the bug is somewhat unlikely in practice: the only way
that a valid text-form GVariant could ever contain a positional
parameter replacement at the end of the string is if this positional
parameter were the only thing being returned. In that case, the user
would likely have opted for a more direct approach.
Unfortunately, this code is also active in the tokenisation phase of
g_variant_parse(), before positional parameters are rejected as invalid
for that case. Anyone who calls this function with a nul-terminated
string (and no end pointer) is vulnerable to a crash from malicious user
input. This can be seen, at the very least with many commandline tools:
$ dconf write /x '%i'
Segmentation fault
We fix this problem by searching for the nul character in this case, in
addition to comparing the end pointer.
This problem is almost certainly limited to being able to cause crashes.
The loop in question only performs reads and, in the security-sensitive
case, the token will be quickly rejected after the loop is finished
(since it starts with '%' and the 'app' pointer is unset). This is
further mitigated by the fact that there are no known cases of GVariant
text format being used as part of a protocol at a privilege barrier.
Currently, the Windows code use Winsock2-specific APIs to try to emulate
calls such as inet_pton(), inet_ntop() and if_nametoindex(), which may not
do the job all the time. On Vista and later, Winsock2 does provide a
proper implementation for these functions, so we can use them if they exist
on the system, by querying for them during g_networking_init(). Otherwise,
we continue to use the original code path for these, in the case of XP and
Server 2003.
This enables many of the network-address tests to pass on Windows as a
result, when the native Winsock2 implementations can be used.
https://bugzilla.gnome.org/show_bug.cgi?id=730352
Check the IPv6 addresses on Windows, as we need to reject those that have
brackets/ports around them as valid addresses in this form would have been
accepted during the call to g_inet_address_new_from_string ().
https://bugzilla.gnome.org/show_bug.cgi?id=730352
Update the .pdb file generation for the MSVC 2010+ DLLs (and the x64 gspawn
helper programs), so that they match the names of the DLLs/EXEs that are
built. Also update the .lib generation so that all will use -$(ApiVersion)
from the property sheets instead of the -2.0 which was previously hard
coded (as we will eventually move into GLib 3.x in the future, for example)
Link to zlib1.lib for all builds, as:
-The notion of zlib1d.lib is rather not standardized across the board for
most cases.
-Easier for the grand all-in-one solution file.
Use the /MP option so that each project can build multiple sources in
parallel, which can cut down release build times by quite a bit. This will
cause a brief warning for debug builds due to their use of /Gm, and builds
would otherwise proceed as they did before.
Unfortunately Visual Studio 2008 is too old to support the /d2Zi+ flag, so
we can't make a better debug situation for it at the moment.
Use Multiprocessor compilation which can cut down build times by quite a
bit and use the /d2Zi+ flag to have better debugging info being logged to
the .pdb for release builds.
These are only applicable for Visual Studio 2010/2012 and later.
Despite linked lists being a fairly fundamental computer science
concept, some developers insist on using:
g_list_length (list) > 0
to determine whether a list is non-empty, rather than using:
list != NULL
Add a comment to the documentation for g_list_length() and
g_slist_length() pointing out the better alternative in the hope that it
will prevent some of this abuse.
https://bugzilla.gnome.org/show_bug.cgi?id=741024
Using G_STRLOC ends up embedding unique strings of the form
__FILE__:__LINE__ in the compiled binary. We can avoid these
by passing __FILE__ and __LINE__ separately when constructing
the warning text.
This probably reduces the size of the binary as __FILE__ is
likely already contained as string otherwise.
Note that for GCC 2.x this changes behavior because G_STRLOC
also contained __PRETTY_FUNCTION__.
https://bugzilla.gnome.org/show_bug.cgi?id=741654
In g_file_make_directory_with_parents(), the my_error variable is used
for several different purposes throughout the whole function, not all of
which are obvious. This explains the situation with some comments.
https://bugzilla.gnome.org/show_bug.cgi?id=719455
We should not advise people to cast the result of
g_hash_table_get_keys_as_array() to a type that looks suitable for use
with g_strfreev(). Advise to use (const gchar **) instead.
Add a GSocketListener test program. Currently the only test is a
regression test for bug 712570 (based on a standalone bug reproducer
provided by Ross Lagerwall).
If all users of a GThreadedSocketService release their references to the
service while a connection thread is running, the thread function will
release the last reference to the service which causes the finalize to
deadlock waiting for all threads to finish (because it's called from the
thread function).
To fix this, don't wait for all threads to finish in the service's
finalize method. Since the threads hold a reference to the service,
finalize should only be called when all threads are finished running (or
have unrefed the service and are about to finish).
https://bugzilla.gnome.org/show_bug.cgi?id=712570
Update glibconfig.h.win32.in so that it will be in-line with the ones that
are produced with configure.ac, for use on Windows builds.
Thanks to Philip Withnall for pointing out the changes needed in bug
727829.
g_get_monotonic_time() and g_get_real_time() now always use different
clocks, so we cannot avoid correcting for their offset. Fixes failure
to time out on Mac OS X.
https://bugzilla.gnome.org/show_bug.cgi?id=738197
Internal allocation size (array->alloc) was being kept to 0 when a new
GByteArray was created from an already existing heap-allocated buffer.
Among other things, this was making g_byte_array_set_size() fully clear all
the buffer contents (not just the newly allocated memory) when
G_DEBUG=gc-friendly was being used...
if (G_UNLIKELY (g_mem_gc_friendly))
memset (array->data + array->alloc, 0, want_alloc - array->alloc);
https://bugzilla.gnome.org/show_bug.cgi?id=738170
