Wherever we use gssize to allow passing -1, we need to ensure we don't
overflow the value by assigning a gsize to it without checking if the
size exceeds the maximum gssize. The safest way to do this is to just
use normal gsize everywhere instead and use gssize only for the
parameter.
Our computers don't have enough RAM to write tests for this. I tried
forcing string->len to high values for test purposes, but this isn't
valid and will just cause out of bounds reads/writes due to
string->allocated_len being unexpectedly small, so I don't think we can
test this easily.
`SOCKS4_CONN_MSG_LEN` failed to account for the length of the final nul
byte in the connect message, which is an addition in SOCKSv4a vs
SOCKSv4.
This means that the buffer for building and transmitting the connect
message could be overflowed if the username and hostname are both
`SOCKS4_MAX_LEN` (255) bytes long.
Proxy configurations are normally statically configured, so the username
is very unlikely to be near its maximum length, and hence this overflow
is unlikely to be triggered in practice.
(Commit message by Philip Withnall, diagnosis and fix by Michael
Catanzaro.)
Fixes: #3461
On recent versions of Debian, PST8PDT is part of the tzdata-legacy
package, which is not always installed and might disappear in future.
Successfully tested with and without tzdata-legacy on Debian unstable.
Signed-off-by: Simon McVittie <smcv@debian.org>
Instead of using timestamp 0 as a magic number (in this case interpreted
as 1970-01-01T00:00:00-08:00), calculate a timestamp from a recent
year/month/day in winter, in this case 2024-01-01T00:00:00-08:00.
Similarly, instead of using a timestamp 15 million seconds later
(1970-06-23T15:40:00-07:00), calculate a timestamp from a recent
year/month/day in summer, in this case 2024-07-01T00:00:00-07:00.
Signed-off-by: Simon McVittie <smcv@debian.org>
In newer tzdata, it is an alias for America/Los_Angeles, which has a
slightly different meaning: DST did not exist there before 1883. As a
result, we can no longer hard-code the knowledge that interval 0 is
standard time and interval 1 is summer time, and instead we need to look
up the correct intervals from known timestamps.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3502
Bug-Debian: https://bugs.debian.org/1084190
[smcv: expand commit message, fix whitespace]
Signed-off-by: Simon McVittie <smcv@debian.org>
Currently, the trash functionality is disabled for system internal mounts.
That might be a problem in some cases. The `x-gvfs-notrash` mount option
allows disabling the trash functionality for certain mounts. Let's add
support for the `x-gvfs-trash` mount option to allow the opposite.
See: https://issues.redhat.com/browse/RHEL-46828
I'd like to enable our GnuTLS GHmac patchset in Fedora in order to
ensure it is receiving sufficient real-world testing, since we've
discovered several bugs thus far. Problem is Fedora has one requirement
that RHEL does not: it needs to build glib as a static lib. This is
needed by QEMU in Fedora for complicated technical reasons that I don't
understand. However, nothing in RHEL needs it. This means we failed to
notice that glib2-static is broken in RHEL, because there is no
gnutls-static! We could fix this by adding a gnutls-static package, but
that seems like overkill, and adding more static libraries where they're
not truly necessary is not the direction we want to move in anyway. So
instead, let's just dlopen GnuTLS to sidestep this problem entirely.
This would not be a good solution for upstream, but upstream has made
clear that this patchset is already non-upstreamable, so it will be fine
for our purposes.
For RHEL we want apps to use FIPS-certified crypto libraries,
and HMAC apparently counts as "keyed" and hence needs to
be validated.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1630260
Replaces: https://gitlab.gnome.org/GNOME/glib/merge_requests/897
This is a build-time option that backs the GHmac API with GnuTLS.
Most distributors ship glib-networking built with GnuTLS, and
most apps use glib-networking, so this isn't a net-new library
in most cases.
=======================================================================
mcatanzaro note:
I've updated Colin's original patch with several enhancements:
Implement g_hmac_copy() using gnutls_hmac_copy(), which didn't exist
when Colin developed this patch.
Removed use of GSlice
Better error checking in g_hmac_new(). It is possible for
gnutls_hmac_init() to fail if running in FIPS mode and an MD5 digest is
requested. In this case, we should return NULL rather than returning a
broken GHmac with a NULL gnutls_hmac_hd_t. This was leading to a later
null pointer dereference inside gnutls_hmac_update(). Applications are
responsible for checking to ensure the return value of g_hmac_new() is
not NULL since it is annotated as nullable. Added documentation to
indicate this possibility.
Properly handle length -1 in g_hmac_update(). This means we've been
given a NUL-terminated string and should use strlen(). GnuTLS doesn't
accept -1, so let's call strlen() ourselves.
Crash the application with g_error() if gnutls_hmac() fails for any
reason. This is necessary because g_hmac_update() is not fallible, so we
have no way to indicate error. Crashing seems better than returning the
wrong result later when g_hmac_get_string() or g_hmac_get_digest() is
later called. (Those functions are also not fallible.) Fortunately, I
don't think this error should actually be hit in practice.
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/903
For each test expected to return valid DNS records, test that the
record variants are not floating references.
Also add an test which checks this explicitly for a simple TXT record.
The return value to `lookup_records()` methods is set as `transfer full`
but the code path in `g_resolver_records_from_res_query()` doesn't
sink the GVariant.
Add the `g_variant_ref_sink()` call when prepending the record, so
the list hold a full reference on each records.
closes#3393
libgirepository is not needed by most of the modules, but it is needed
by the `g-ir-scanner` generated dumper program. If we don’t explicitly
include the local version of it here, Meson will implicitly link against
it anyway, and that might pull in a different version, or try to link
against a half-built local version as the build ordering dependency tree
won’t reflect this relationship.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3401
There is a meson option (gir_dir_prefix), but without being passed in here
the files would always get installed into the default location (datadir).
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
This should test the limits of loading 4GB files on i386 platforms, such
as the Hurd CI runner. On such platforms, `sizeof(size_t) == 4`.
This should fix the compiler warning from
https://gitlab.gnome.org/GNOME/glib/-/jobs/3989442:
```
../gio/tests/file.c:2931:51: error: left shift count >= width of type [-Werror=shift-count-overflow]
2931 | static const gsize testfile_4gb_size = ((gsize) 1 << 32) + (1 << 16); /* 4GB + a bit */
| ^~
cc1: all warnings being treated as errors
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
They take too long to include in a normal test run. They’ll still be run
in CI once a week as part of our scheduled slow test job.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The tests - one for sync, one for async - create a sparse file for
this purpose, so this should be cheap on the fileystem.
Of course, the test still allocates >4GB of memory for the data that it
returns from g_file_load_contents(), I hope the CI test runners can deal
with that.
GByteArray is limited to 4GB in size and the current code silently
overflows when that happens.
Replace both load_contents() and load_contents_async() implementations
with a version that uses realloc() and gsize to maintain the array.
Previously it was mapped (as a default) to `G_IO_ERROR_FAILED`.
It’s the error that macOS returns when trying to connect to a socket which
is bound but not listened to. Linux returns `ECONNREFUSED` in this case.
It’s helpful if they both map to the same `GIOError` value.
This should fix the `/socket-client/connection-fail` test on macOS,
which is currently
[failing](https://gitlab.gnome.org/GNOME/glib/-/jobs/3970547) with:
```
# GLib-GIO-DEBUG: GSocketClient: Starting TCP connection attempt
# GLib-GIO-DEBUG: GSocketClient: Connection attempt failed: Can't assign requested address
# GLib-GIO-DEBUG: GSocketClient: Starting new address enumeration
# GLib-GIO-DEBUG: GSocketClient: Address enumeration completed (out of addresses)
# GLib-GIO-DEBUG: GSocketClient: Address enumeration failed: (null)
# GLib-GIO-DEBUG: GSocketClient: Connection failed: Could not connect to localhost: Can't assign requested address
not ok /socket-client/connection-fail - GLib-GIO:ERROR:../gio/tests/gsocketclient-slow.c:231:test_connection_failed: assertion failed (local_error == (g-io-error-quark, 39)): Could not connect to localhost: Can't assign requested address (g-io-error-quark, 0)
Bail out!
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
See: #3184Fixes: #3394
Once the task is completed (and `g_task_return_*()` has been called),
the task is no longer needed. It would make more sense to unref it in
`complete_connection_with_error()`, where `g_task_return_*()` is called,
but that complicates other call sites significantly, so I didn’t do it.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3184
As with the previous two commits, the results of calling
`gi_repository_get_loaded_namespaces()` were previously
non-deterministic due to being generated by iterating over a hash table,
which has a non-deterministic iteration order.
Fix that by using the new `ordered_typelibs` and `ordered_lazy_typelibs`
arrays to provide deterministic ordering.
At the same time, significantly reduce the number of allocations needed
to build the return value — previously the results would be built as a
linked list before being turned into an array. The linked list is now
banished to history.
Add some more unit tests to maximise test coverage of this method.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3303
As with the previous commit, finding a `GIBaseInfo` matching the given
error domain was non-deterministic because it iterated through a hash
table of typelibs. Hash table iteration is non-deterministic.
Change the method to instead use the `ordered_typelibs` and
`ordered_lazy_typelibs` arrays to give deterministic iteration order.
Add a unit test, although it can’t test the interesting case of an error
domain which is present in both `GioUnix`/`GioWin32` and `Gio`, because
no such error domain exists.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
When faced with a `GType` which is present in multiple typelibs, the old
implementation was not deterministic, as it iterated over a hash table
of typelibs. The iteration order of a hash table is not deterministic.
Use the new `ordered_typelibs` and `ordered_lazy_typelibs` arrays to
iterate instead, making the order deterministic.
Add a unit test to check this. In particular, to check that symbols
which are present in both `Gio` and `GioUnix` are correctly resolved as
being from `GioUnix`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
The iteration code used `g_string_overwrite_len()` to try and simplify
buffer allocation and growth, but seemingly forgot to handle the fact
that it doesn’t nul-terminate what it overwrites: the method is intended
to be used to splice bits into longer strings, not to overwrite an
entire nul-terminated string.
This meant that when iterating over a comma-separated `c_prefix` like
`GUnix,G`, on the second iteration `g_string_overwrite_len()` would be
used to write `G` into index 0 of the already-set `GUnix` string in the
buffer, leading to the first iteration happening all over again and the
`G` prefix being ignored.
This led to symbols failing to be matched to the `GioUnix` typelib, even
though they should have been.
This will be checked by a test in the following commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
There are various places where the set of typelibs is iterated over or
returned in an ordered way. In order to keep results deterministic and
reproducible, we need to keep this set ordered.
Keep a `GPtrArray` of the typelibs (one for fully-loaded ones and one
for lazy ones) alongside the existing hash tables. This will be used for
iteration in the next few commits.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3303
Almost identically to the previous commit, fix a similar latent bug in
`g_dbus_connection_export_action_group()`, which was not ready to handle
the fledgling `GActionGroupExporter` being freed early on an error
handling path.
See the previous commit message for details of the approach.
This includes a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3366
This latent bug wasn’t triggered until commit 3f30ec86c (or its
cherry-pick onto `glib-2-80`, 747e3af99, which was first released in
2.80.1).
That change means that `g_menu_exporter_free()` is now called on the
registration failure path by `g_dbus_connection_register_object()`
before it returns. The caller then tries to call `g_slice_free()` on the
exporter again. The call to `g_menu_exporter_free()` tries to
dereference/free members of the exporter which it expects to be
initialised — but because this is happening in an error handling path,
they are not initialised.
If it were to get any further, the `g_slice_free()` would then be a
double-free on the exporter allocation.
Fix that by making `g_menu_exporter_free()` robust to some of the
exporter members being `NULL`, and moving some of the initialisation
code higher in `g_dbus_connection_export_menu_model()`, and removing the
duplicate free code on the error handling path.
This includes a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3366
