There are many cases where a default TLS database is not able to be
defined within the constraints of a system. For example glib-networking
(or glib-openssl) cannot retrieve the default certificate store on iOS
or Android and need to be initialized from a cert file of certificates
bundled with the application.
Previously GStreamer was relying on a custom patch to glib-networking to
populate the default database from the file pointed to by the
CA_CERTIFICATES environment variable however the mechanism that enabled
this was recently remove from glib-networking.
Adding a more generic g_tls_backend_set_default_database() API allows
application developers to override the default database using their own
certificates as well as allowing equivalent functionality on Android/iOS
(or others) as on the default database handling Linux.
Fixes https://gitlab.gnome.org/GNOME/glib-networking/issues/35
The ::network-changed signal is documented to indicate any change in
network configuration, which doesn't necessarily imply a property
change - additional services becoming available after connecting to
a VPN comes to mind for instance.
In order to match the "native" network monitor's behavior, always
emit the signal when it's in response to the 'changed' D-Bus signal.
Also emit the signal unconditionally when loading the initial property
values, to allow clients to differentiate between "offline" meaning
"offline" and "offline" meaning "uninitialized".
With 0d685b4946, we now encode resource
data as a string. Strings have trailing nul terminators. A C compiler
will happily ignore the fact that the nul terminator exceeds the stated
array length, and will drop it — but a C++ compiler won’t, and will
raise:
error: initializer-string for array of chars is too long [-fpermissive]
Fix that by increasing the array length by 1, and subtracting it again
in the GStaticResource struct.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This reverts commit 3c1902fcf9.
This was accidentally re-added from an old version of the branch before
!265 was merged. It should not have been re-added.
Rearrange the code so we try version 3 first,
falling back to version 2 and then version 1.
We still do a construct-time check to ensure
that we work with unsupported versions.
Note that this also takes care of setting the
initial property values in the version 1 case.
Version 3 of the network monitor portal interface adds
a CanReach method. Use it to implement can_reach.
The docs state that can_reach will either return TRUE
or set an error. So, set an error of G_IO_ERROR_HOST_UNREACHABLE
when the portal returns FALSE for CanReach.
GSettings XML schema files are installed in a well known directory
under Glib's installation directory: `glib-2.0/schemas`. However,
the Glib installation directory might vary, so the exact location of
the schema files might be unknown.
The information regarding this directory has been added to GIO's
pkg-config file, so it can be checked, and also overrided, by using
the command line utility.
The source callback for a GCancellable should have the cancellable itself
as first argument.
This was not the case, and when this code was hit, we were instead trying
to treat the pointer as a CommunicateState reference and thus wrongly
deferencing it, causing a memory error and a crash.
Some Testing revealed encoding resource data with string
escape codes to compile significantly quicker compared
to the same data encoded as an array with hexadecimal numbers.
See #1489
This is a follow-up to commit 614adf8a75,
which started generating two new files as part of the test; they need to
be cleaned up before distcheck will pass.
Ideally, the test should run a temporary directory and wipe that
directory itself before exiting, but that’s a bit of a big change to
make right now. Deferred to
https://gitlab.gnome.org/GNOME/glib/issues/1495.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In file gio/gtestdbus.c, function watch_parent, there is a loop which
waits for commands sent from the parent process and kills all processes
recorded in 'pids_to_kill' array on parent process exit. The detection
of parent process exit is done by calling g_poll and checking whether
the returned event is G_IO_HUP. However, 'revents' is a bit mask, and
we should use a bitwise-AND check instead of the equality check here.
It seems to work fine on Linux, but it fails on FreeBSD because the
g_poll returns both G_IO_IN and G_IO_HUP on pipe close. This means the
watcher process continues waiting for commands after the parent process
exit, and g_io_channel_read_line returns G_IO_STATUS_EOF with 'command'
set to NULL. Then the watcher process crashes with segfault when calling
sscanf because 'command' is NULL. Since the test result is already
reported by the parent process as 'OK', this kind of crash is likely to
be unnoticed unless someone checks dmesg messages after the test:
pid 57611 (defaultvalue), uid 1001: exited on signal 11
pid 57935 (actions), uid 1001: exited on signal 11
pid 57945 (gdbus-bz627724), uid 1001: exited on signal 11
pid 57952 (gdbus-connection), uid 1001: exited on signal 11
pid 57970 (gdbus-connection-lo), uid 1001: exited on signal 11
pid 57976 (gdbus-connection-sl), uid 1001: exited on signal 11
pid 58039 (gdbus-exit-on-close), uid 1001: exited on signal 11
pid 58043 (gdbus-exit-on-close), uid 1001: exited on signal 11
pid 58047 (gdbus-exit-on-close), uid 1001: exited on signal 11
pid 58051 (gdbus-exit-on-close), uid 1001: exited on signal 11
pid 58055 (gdbus-export), uid 1001: exited on signal 11
pid 58059 (gdbus-introspection), uid 1001: exited on signal 11
pid 58065 (gdbus-names), uid 1001: exited on signal 11
pid 58071 (gdbus-proxy), uid 1001: exited on signal 11
pid 58079 (gdbus-proxy-threads), uid 1001: exited on signal 11
pid 58083 (gdbus-proxy-well-kn), uid 1001: exited on signal 11
pid 58091 (gdbus-test-codegen), uid 1001: exited on signal 11
pid 58095 (gdbus-threading), uid 1001: exited on signal 11
pid 58104 (gmenumodel), uid 1001: exited on signal 11
pid 58108 (gnotification), uid 1001: exited on signal 11
pid 58112 (gdbus-test-codegen-), uid 1001: exited on signal 11
pid 58116 (gapplication), uid 1001: exited on signal 11
pid 58132 (dbus-appinfo), uid 1001: exited on signal 11
If the watcher process crashes before killing the dbus-daemon process
spawned by the parent process, the dbus-daemon process will keep running
after all tests complete. Due to the implementation of 'communicate'
function in Python subprocess, it causes meson to crash. 'communicate'
assumes the stdout and stderr pipes are closed when the child process
exits, but it is not true if processes forked by the child process
doesn't exit. It causes Python subprocess 'communicate' function to
block on the call to poll until the timeout expires even if the test
finishes in a few seconds. Meson assumes the timeout exception always
means the test is still running. It calls 'communicate' again and
crashes because pipes no longer exist.
https://gitlab.gnome.org/Infrastructure/GitLab/issues/286https://github.com/mesonbuild/meson/issues/3967https://bugs.python.org/issue30154
Previously, glocalfile.c would not set file system metadata for
the free/used key for file systems which reported 0 free space. This is
because some file systems don’t set that metadata when you call
statfs(), so we can’t reliably report it. However, some do, and they
can legitimately set f_bavail and f_bfree to 0 if the file system is
full.
In order to avoid that, always set the file system metadata unless the
file system is FUSE or ncpfs.
This is a partial revert of commit 0b9f24c1e1: instead of the changes
made in that commit, I think we should maintain a blacklist of file
systems which are known to not correctly report free space.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/328
Similar issue was fixed with commit f929d148, but it's happening again.
Define G_MESSAGES_DEBUG=all when running CI to ensure we won't regress
anymore.
In order to determine whether to trash a file to the home directory, we
compare its st_dev to our home directory's st_dev field.
This is the wrong thing to do on overlayfs when deleting files, because
st_dev contains the ID of the filesystem providing the file (which can
be the lower or upper filesystem), but directories always return the ID
of the overlayfs. Thus the comparison fails and we are unable to trash
the file.
Fix this by checking st_dev of the parent directory when we are deleting
a file.
Also adjust `test_trash_not_supported` for this - make its st_dev check
look at the parent directory's `st_dev` rather than the temporary file's
own.
Fixes#1027.
The documentation was unclear about what error codes would be returned
on attempting to open an empty or corrupt GVDB file. Previous versions
of the documentation incorrectly said that corrupt GVDB files were
considered equivalent to empty ones.
A recent commit has clarified the documentation to include its error
handling behaviour.
Update the two users of GVDB within GLib, GResource and GSettingsSource,
to follow this change, and add unit tests for them both.
Other users of the GVDB copylib will need to update their copy and make
appropriate changes if they have bugs in their handling of this
situation. dconf is one example of this. GVDB should be updated from
https://gitlab.gnome.org/GNOME/gvdb.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1454
While mountpoints are *not* symlinks, strictly speaking,
they works in a similar enough way, so consider them to be
symlinks for the purpose of querying local file info.
On Windows st_ctime field is the file creation time.
POSIX mandates that field to be the file state change time.
Naturally, glib code interpreted st_ctime as POSIX suggested,
and the result was bad.
Fix this by introducing special W32-only logic for setting
attributes from st_ctime field.
Fixes issue #1452.
We now send the fallback SCSV, meaning use of this function will cause
modern servers to immediately terminate the connection, so let's warn
API users to expect that behavior and be crystal clear that this
function should only be used as a fallback when a normal connection
attempt has already failed.
Also, the documentation is mostly duplicated between the property and
the function, so let's just reference the function documentation from
the property.
7efd76dd67 added these configure time tests to work around a bug
with older Android. Since the test didn't take Windows into account it
wrongfully applied the workaround on Windows too, breaking the build.
With meson this wasn't an issue since the check is skipped on Windows there
and our CI didn't catch this issue.
Change the test to run on Android only for meson and autotools.
This also makes it clear that the test+code can be dropped again if we stop
supporting older Android versions at some point.
GLib currently tries to use FAM volume monitor for monitoring files
within home on NFS. If FAM support is not available, it fallbacks by
default to GInotifyFileMonitor. I think we should fallback to
GPollFileMonitor instead, because inotify is not reliable on NFS,
which may cause issues for dconf. With this patch, it should be safe to
not build libgiofam and still be sure that dconf works properly if home
is mounted on NFS. I think this might be a first step to remove FAM
support from GLib completely, because gamin is buggy and dead for
several years already. Gamin just polls files on NFS anyway. This
change applies on files only, because GPollFileMonitor seems doesn't
support dirs, however it should be enough for dconf. The other
drawback is that one can't set poll timeout currently. Just a note
that this can still be overwritten by GIO_USE_FILE_MONITOR.
Releasing GVolumeMonitor before g_volume_mount finish cause that
g_volume_get_mount returns NULL, because the mount is not correctly
propagated to the volume.
https://gitlab.gnome.org/GNOME/glib/issues/1458
The gresource code uses libelf if available but that also depends on mmap but isn't
guarded with HAVE_MMAP. This can make the build fail under MSYS2 where a mingw version
of libelf exists but there is no mmap.
Instead of guarting the libelf code with HAVE_LIBELF add a new macro named USE_LIBELF
which is only defined if libelf and mmap support are available.
Also install the mingw libelf version for CI so we catch similar errors in the future.
It is a bug if we distribute files which are generated at build time —
they should be built on the machine which is compiling GLib, not be
shipped in the tarball.
This brings the autotools-generated tarball in line with the
ninja-generated one, with the exception of man pages and gtk-doc HTML
output.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The documentation claims that g_volume_get_mount should succeed after
g_volume_mount. Let's update mounts before releasing g_volume_mount to
be sure that the mount is added to the corresponding volume. The same
is done in GVfsUDisks2VolumeMonitor.
https://gitlab.gnome.org/GNOME/glib/issues/1458
The network monitor portal interface is changing.
Version 2 is no longer using properties, but getters
instead (this lets the portal apply access control
and avoid sending information to non-networked
sandboxes).
To support both version 1 and 2 of the interface,
we stop using generated code and instead deal with
the api differences in our own code, which is not
too difficult.
Support version 1 as well
The new python module, added with 0.46, works with Python 2 and 3 and
allows to pass a path for the interpreter to use, if the need arises.
Previously the meson build set PYTHON, used in the shebang line of
the scripts installed by glib, to the full path of the interpreter.
The new meson module doesn't expose that atm, but we should set it to
a executable name anyway, and not a full path.
Several of our tools are installed and are used by other projects to
generate code. However, there is no 'install' when projects use glib
as a subproject.
We need some way for glib to 'provide' these tools so that when some
project uses glib as a subproject, find_program('glib-mkenums') will
transparently return the glib-mkenums we just built.
Starting from Meson 0.46, this can be done with the
`meson.override_find_program()` function.
As a bonus, the Meson GNOME module will also use these
'overriden'/'provided' programs instead of looking for them in PATH.
PEP8 says that:
"Comparisons to singletons like None should always be done with is or
is not, never the equality operators."
glib uses a mix of "== None" and "is None". This patch changes all
cases to the latter.
Use g_test_skip() so that the TAP output is correct for the tests,
rather than printing using g_printerr().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/640
Use either g_get_real_time() or g_date_time_new_now_local(). This means
we don’t need to worry about time_t being 32b in future (the year 2038
problem), and it makes the need for error handling a bit more explicit.
Improve the error handling in several cases.
Based on a patch by Niels De Graef
(https://gitlab.gnome.org/GNOME/glib/merge_requests/142).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1402
Apparently this is needed for building PE libraries. It makes no
difference on Linux, where linking of the GLib symbols in the inotify
file monitor code is done lazily.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1201
The tests array was being wiped out by an assignment instead of an
append. This adds another 19 tests to what’s typically being run
already.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This was missed in !137 because some of the GIO tests weren’t being run
under Meson (see following commits).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Adds tests to cover this case and similar cases for various GResource
methods in future.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/927
When changing the locale using setlocale(), duplicate the old locale
value before updating it, so that we can safely restore the old locale
after running the test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
