GitLab

!552 (commit 9eed22b3) fixed this for the tests that failed on i686,
but this additional test failed on Debian's s390x port
(IBM z/Architecture, 64-bit big-endian).
Signed-off-by: Simon McVittie <smcv@collabora.com>

On glib-2-58 branch we don't have !455, thus we need aligned data
for the gvariant tests to not fail on i686.

Fixes #1626

On non-systemd Gentoo systems the chosen timezone is expressed in
/etc/timezone and /etc/localtime may be a copy of the timezone
file instead of symlink. Add this path to the fallback test to
not regress dates into UTC.

In date time formatting routine, instead of converting from UTF-8 to
locale charset and then from locale charset to UTF-8, store all
intermediate result in UTF-8.

This solves the issue where user provided UTF-8 format string might be
unrepresentable in the current locale charset.

Fixes issue #1605.

opendir and closedir are not async-signal-safe, these may call malloc
under the hood and cause a deadlock in a multi-threaded program.
This only affected Linux when /proc is mounted, other systems use a
slower path that iterates through all potential file descriptors.
Fixes a long-standing problem (since GLib 2.14.2).

Closes #945 and #1014

There are languages where a name of one month is a substring of another.
Instead of stopping search on the first match use the month that
constitutes the longest match.

(Backport to glib-2-58: Fix minor merge conflict.)

Fixes #1343.

This was causing a crash, because we were first removing an item, freeing
both the instance itself and the key, and then trying to reuse those.

So, in this case, instead of reassigning an item, we can just return TRUE
as we have already the item at the right place, while it's not needed to
update the modified timestamp, since no modification happened in reality.

Fixes #1588

Verify that we can move a bookmark item to the same name, but actually this
causes a crash right now.

Previously, the markup parsing test would load a given markup file and
try to parse it several ways. It would return as soon as one of the
attempts failed — meaning that bugs only seen with non-nul-terminated,
or differently chunked, parse runs could never be caught.

Rework the tests so that all markup files are tested all ways, and we
assert that all ways of parsing them give the same result.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Previously, the element name validation only happened if a start_element
callback was specified on the context. Element name validation should be
unconditional.

This was causing test-5.gmarkup to fail when run against the improved
tests in the following commit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

When extracting a UTF-8 character to put in an error message on parse
failure, pass the remaining buffer length to utf8_str() to avoid it
running off the end of the input buffer. It previously assumed that the
buffer was nul-terminated, which was the case in all the tests until
now.

A following commit will add test coverage for this.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

When using GMarkup to parse a string, the string can be provided with an
explicit length specified, or with no length and a nul terminator
instead. Run all the GMarkup tests both ways, to catch problems with
length checks, or with nul terminator checks.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

This doesn’t trigger any new failures, but is distinct from other tests
we have, so would be good to retain.

Related to commit cec71705.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

These were callers which explicitly specified the string length to
g_utf8_validate(), when it couldn’t be negative, and hence should be
able to unconditionally benefit from the increased string handling
length.

At least one call site would have previously silently changed behaviour
if called with strings longer than G_MAXSSIZE in length.

Another call site was passing strlen(string) to g_utf8_validate(), which
seems pointless: just pass -1 instead, and let g_utf8_validate()
calculate the string length. Its behaviour on embedded nul bytes
wouldn’t change, as strlen() stops at the first one.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

This is a variant of g_utf8_validate() which requires the length to be
specified, thereby allowing string lengths up to G_MAXSIZE rather than
just G_MAXSSIZE.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Signed-off-by: Philip Withnall <withnall@endlessm.com>

When validating a string to see if it’s valid UTF-8, we pass a gsize to
g_utf8_validate(), which only takes a gssize. For large gsize values,
this will result in the gssize actually being negative, which will
change g_utf8_validate()’s behaviour to stop at the first nul byte. That
would allow subsequent nul bytes through the string validator, against
its documented behaviour.

Add a test case.

oss-fuzz#10319
Signed-off-by: Philip Withnall <withnall@endlessm.com>

As with the previous commit, when getting a child from a serialised
tuple, check its offset against the length of the serialised data of the
tuple (excluding the length of the offset table). The offset was already
checked against the length of the entire serialised tuple (including the
offset table) — but a child should not be able to start inside the
offset table.

A test is included.

oss-fuzz#9803
Signed-off-by: Philip Withnall <withnall@endlessm.com>

When getting a child from a serialised variable array, check its offset
against the length of the serialised data of the array (excluding the
length of the offset table). The offset was already checked against the
length of the entire serialised array (including the offset table) — but a
child should not be able to start inside the offset table.

A test is included.

oss-fuzz#9803
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Previously, GVariant has allowed ‘arbitrary’ recursion on GVariantTypes,
but this isn’t really feasible. We have to deal with GVariants from
untrusted sources, and the nature of GVariantType means that another
level of recursion (and hence, for example, another stack frame in your
application) can be added with a single byte in a variant type signature
in the input. This gives malicious input sources far too much leverage
to cause deep stack recursion or massive memory allocations which can
DoS an application.

Limit recursion to 128 levels (which should be more than enough for
anyone™), document it and add a test. This is, handily, also the limit
of 64 applied by the D-Bus specification (§(Valid Signatures)), plus a
bit to allow wrapping of D-Bus messages in additional layers of
variants.

oss-fuzz#9857
Signed-off-by: Philip Withnall <withnall@endlessm.com>

When checking whether a serialised GVariant tuple is in normal form,
it’s possible for `offset_ptr -= offset_size` to underflow and wrap
around, resulting in gvs_read_unaligned_le() reading memory outside the
serialised GVariant bounds.

See §(Tuples) in gvariant-serialiser.c for the documentation on how
tuples are serialised. Briefly, all variable-length elements in the
tuple have an offset to their end stored in an array of offsets at the
end of the tuple. The width of each offset is in offset_size. offset_ptr
is added to the start of the serialised tuple to get the offset which is
currently being examined. The offset array is in reverse order compared
to the tuple elements, hence the subtraction.

The bug can be triggered if a tuple contains a load of variable-length
elements, each of whose length is actually zero (i.e. empty arrays).

Includes a unit test.

oss-fuzz#9801
Signed-off-by: Philip Withnall <withnall@endlessm.com>

This test isn't inherently slow, but it produces so much output that
it can take a minute or more on hardware with weak I/O performance.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Formatting code for `%z` specifier incorrectly assumed that sign of
offset from UTC can be recovered from the number of hours alone, which
is not true for offsets between -01:00 and +00:00.

Extract and format sign separately to avoid the problem.

Issue #1337.

g_variant_valist_free_nnp does not take into account ^*ay, which causes
crash when trying to use these types together with
g_variant_iter_loop().

This will exhibit bugs in g_variant_valist_free_nnp() as these types are
not properly handled.

When g_date_set_parse was used with more than one locale it could
incorrectly retain information from previous one. Reinitialize all
locale specific data inside g_date_prepare_to_parse to avoid the issue.

Update the abbreviated month name in the test to match the GNU libc
translation, coming from CLDR.

Fixes #1562

Fedora is using https://fedoraproject.org/wiki/Changes/Annobin
to try to ensure that all objects are built with hardening flags.
Pass down `CFLAGS` to ensure the SystemTap objects use them.

Without gatomic.h, build fails on:
In file included from garcbox.c:24:0:
garcbox.c: In function ‘g_atomic_rc_box_acquire’:
grefcount.h:101:13: error: implicit declaration of function ‘g_atomic_int_get’; did you mean ‘__atomic_store’? [-Werror=implicit-function-declaration]
     (void) (g_atomic_int_get (rc) == G_MAXINT ? 0 : g_atomic_int_inc ((rc))); \
             ^
garcbox.c:292:3: note: in expansion of macro ‘g_atomic_ref_count_inc’
   g_atomic_ref_count_inc (&real_box->ref_count);
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

meson: Mark 1bit-emufutex test as slow

See merge request !406

(cherry picked from commit 5c22b2dd)

442b54f0 meson: Mark 1bit-emufutex test as slow

This avoids the convenience library being treated as though it was
an installed static library (objects not included in the dependent
static library, and convenience library being listed in the pkg-config
metadata), both of which would make static linking impossible.
This is a workaround for meson not having
https://github.com/mesonbuild/meson/pull/3939 merged yet.

Fixes: #1536Signed-off-by: Simon McVittie <smcv@collabora.com>

Previously, it was installed unmodified by the Meson build system.

We don't need to define @bindir@, because gtester-report never
actually referred to it. We also don't need a definition of
GTESTER_REPORT for use by GLib itself, because its last use was removed
in 2013 (https://bugzilla.gnome.org/show_bug.cgi?id=709995).

Fixes: #1544Signed-off-by: Simon McVittie <smcv@collabora.com>

Detected by Debian's Lintian tool.
Signed-off-by: Simon McVittie <smcv@collabora.com>

This makes it easier to debug test failures, by ensuring that g_debug()
and g_test_message() are printed as TAP diagnostics.

Fixes: #1528Signed-off-by: Simon McVittie <smcv@collabora.com>

Closes #1527

According to
http://blog.kalmbach-software.de/2008/02/28/howto-correctly-read-reparse-data-in-vista/
we only need FILE_READ_EA, and should also use wider share flags.