summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* gmetrics: Run metrics timeouts on dedicated threadhalfline/debug-metricsRay Strode2023-04-121-1/+19
| | | | | Some of the timeout handlers can take seconds to complete, so run them from their own thread instead of the main thread.
* gmem: Change out how memory is allocated in GLibRay Strode2023-04-121-19/+11
|
* glist: Add debug metrics for gnome-shellRay Strode2023-04-123-6/+237
|
* garray: track array allocationsRay Strode2023-04-121-2/+233
|
* gmain: Add debug metrics for gnome-shellRay Strode2023-04-128-34/+641
|
* gsignal: Add debug metrics for gnome-shellRay Strode2023-04-121-1/+98
|
* gsignal: add g_signal_name_unlocked helperRay Strode2023-04-121-5/+16
| | | | | This function fetches the name of a signal from its id. It's like g_signal_name, but works when the signal lock is held.
* gobject: Add debug metrics for gnome-shellRay Strode2023-04-121-3/+128
|
* ghash: Add debug metrics for gnome-shellRay Strode2023-04-121-0/+116
|
* gmetrics: Add debug api for print metricsRay Strode2023-04-1211-3/+7207
| | | | | | | | In order to get a handle on memory usage it would be good to get reports of various types of object usage over time. This commit provides a little api for generating CSV files to dump the data to.
* ghash: Allow tweaking hash table shift by environment variableRay Strode2023-03-311-2/+2
| | | | | | | | | | | The shift controls the capacity of the hash table before it needs to be resized. This commit makes the shift configurable through the G_HASH_TABLE_MIN_SHIFT environment variable.
* Revert "Revert "gmain: Warn when g_source_remove() fails""Ray Strode2023-03-311-0/+2
| | | | This reverts commit 8ab051c5c796e3d17863399bbf9164a71ba0fb06.
* gobject: Don't crash if debug hash doesn't match expectationsRay Strode2021-12-151-2/+1
| | | | | | | At the moment if a GObject fails to chain up to finalize the object won't get removed from the hash at finalize time. This commit drops the assertions.
* Add g_source_set_dispose_function() for setting a dispose function for GSourceSebastian Dröge2021-12-152-0/+77
| | | | | | | | | | | | | | This allows GSource implementors to safely clear any other references to the GSource while the GSource is still valid, unlike when doing the same from the finalize function. After the dispose function has run, it is valid for the reference count of the GSource to be > 0 again to allow the case where another thread in the mean-time got access to the GSource reference before the dispose function was called. This allows fixing a thread-safety issue in the GCancellable, GstBus and various other GSource implementations.
* gdatainputstream: replace easy use of g_memdup()Michael Catanzaro2021-07-141-1/+2
| | | | | | | This code is passing a gsize, so might as well switch this to g_memdup2(). This is the only use of g_memdup() in GLib 2.56 that is not part of GLib 2.58. All other uses analyzed in glib!2000.
* gio: Use g_memdup2() instead of g_memdup() in obvious placesPhilip Withnall2021-07-148-19/+29
| | | | | | | | | | | | | | Convert all the call sites which use `g_memdup()`’s length argument trivially (for example, by passing a `sizeof()`), so that they use `g_memdup2()` instead. In almost all of these cases the use of `g_memdup()` would not have caused problems, but it will soon be deprecated, so best port away from it. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Helps: #2319 (cherry picked from commit be8834340a2d928ece82025463ae23dee2c333d0)
* gobject: Use g_memdup2() instead of g_memdup() in obvious placesPhilip Withnall2021-07-144-7/+12
| | | | | | | | | | | | | | Convert all the call sites which use `g_memdup()`’s length argument trivially (for example, by passing a `sizeof()`), so that they use `g_memdup2()` instead. In almost all of these cases the use of `g_memdup()` would not have caused problems, but it will soon be deprecated, so best port away from it. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Helps: #2319 (cherry picked from commit 6110caea45b235420b98cd41d845cc92238f6781)
* ghash: Use g_memdup2() instead of g_memdup()Simon McVittie2021-07-141-1/+2
| | | | | | | | Backport of part of commit 0736b7c1e7cf4232c5d7eb2b0fbfe9be81bd3baa to the simpler structure of the GHashTable code in glib-2-58. Helps: #2319 Signed-off-by: Simon McVittie <smcv@collabora.com>
* glib: Use g_memdup2() instead of g_memdup() in obvious placesPhilip Withnall2021-07-146-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | | Convert all the call sites which use `g_memdup()`’s length argument trivially (for example, by passing a `sizeof()` or an existing `gsize` variable), so that they use `g_memdup2()` instead. In almost all of these cases the use of `g_memdup()` would not have caused problems, but it will soon be deprecated, so best port away from it In particular, this fixes an overflow within `g_bytes_new()`, identified as GHSL-2021-045 (aka CVE-2021-27219) by GHSL team member Kevin Backhouse. Adapted for GLib 2.58 by Simon McVittie. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Fixes: CVE-2021-27219 Fixes: GHSL-2021-045 Helps: #2319 (cherry picked from commit 0736b7c1e7cf4232c5d7eb2b0fbfe9be81bd3baa) [Backport to 2.58: Omit changes to ghash.c, will be a separate commit] [Backport to 2.58: Omit changes to giochannel.c, not needed in this branch] [Backport to 2.58: Omit changes to uri test, not needed in this branch] Signed-off-by: Simon McVittie <smcv@collabora.com>
* gstrfuncs: Add internal g_memdup2() functionPhilip Withnall2021-07-144-0/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | This will replace the existing `g_memdup()` function for use within GLib. It has an unavoidable security flaw of taking its `byte_size` argument as a `guint` rather than as a `gsize`. Most callers will expect it to be a `gsize`, and may pass in large values which could silently be truncated, resulting in an undersize allocation compared to what the caller expects. This could lead to a classic buffer overflow vulnerability for many callers of `g_memdup()`. `g_memdup2()`, in comparison, takes its `byte_size` as a `gsize`. Spotted by Kevin Backhouse of GHSL. In GLib 2.68, `g_memdup2()` will be a new public API. In this version for backport to older stable releases, it’s a new `static inline` API in a private header, so that use of `g_memdup()` within GLib can be fixed without adding a new API in a stable release series. Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Helps: CVE-2021-27219 Helps: GHSL-2021-045 Helps: #2319 (cherry picked from commit 5e5f75a77e399c638be66d74e5daa8caeb433e00)
* gsignal: Plug g_signal_connect_object leakRay Strode2020-10-141-0/+1
| | | | | | | | | | | | | commit 916297be799ee001b4a214cc52c3b960bb0b5deb added a hash table to provide constant time lookups of signal handlers. Unfortunately, that commit neglected to remove handlers from g_signal_connect_object calls from the hash table that are disconnected implicitly when the associated object goes away. This commit addresses that bug by changing the closure invalidate handler associated with the signal connection to properly remove the handler from the hash table.
* gfile: Limit access to files when copyingOndrej Holy2020-10-141-5/+6
| | | | | | | | file_copy_fallback creates new files with default permissions and set the correct permissions after the operation is finished. This might cause that the files can be accessible by more users during the operation than expected. Use G_FILE_CREATE_PRIVATE for the new files to limit access to those files.
* gdbus-codegen: honor "Property.EmitsChangedSignal" annotationsThomas Jost2020-10-144-11/+56
| | | | Co-Authored-by: Andy Holmes <andrew.g.r.holmes@gmail.com>
* codegen: Change pointer casting to remove type-punning warningsRobert Ancell2020-10-141-11/+11
| | | | | | | The existing code was generating code with undefined results that modern compilers warn about: accounts-generated.c:204:23: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] (GDBusArgInfo **) &_accounts_accounts_method_info_list_cached_users_OUT_ARG_pointers,
* credentials: Invalid Linux struct ucred means "no information"Simon McVittie2020-10-141-3/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Linux, if getsockopt SO_PEERCRED is used on a TCP socket, one might expect it to fail with an appropriate error like ENOTSUP or EPROTONOSUPPORT. However, it appears that in fact it succeeds, but yields a credentials structure with pid 0, uid -1 and gid -1. These are not real process, user and group IDs that can be allocated to a real process (pid 0 needs to be reserved to give kill(0) its documented special semantics, and similarly uid and gid -1 need to be reserved for setresuid() and setresgid()) so it is not meaningful to signal them to high-level API users. An API user with Linux-specific knowledge can still inspect these fields via g_credentials_get_native() if desired. Similarly, if SO_PASSCRED is used to receive a SCM_CREDENTIALS message on a receiving Unix socket, but the sending socket had not enabled SO_PASSCRED at the time that the message was sent, it is possible for it to succeed but yield a credentials structure with pid 0, uid /proc/sys/kernel/overflowuid and gid /proc/sys/kernel/overflowgid. Even if we were to read those pseudo-files, we cannot distinguish between the overflow IDs and a real process that legitimately has the same IDs (typically they are set to 'nobody' and 'nogroup', which can be used by a real process), so we detect this situation by noticing that pid == 0, and to save syscalls we do not read the overflow IDs from /proc at all. This results in a small API change: g_credentials_is_same_user() now returns FALSE if we compare two credentials structures that are both invalid. This seems like reasonable, conservative behaviour: if we cannot prove that they are the same user, we should assume they are not. Signed-off-by: Simon McVittie <smcv@collabora.com>
* GDBus: prefer getsockopt()-style credentials-passing APIsSimon McVittie2020-10-142-2/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conceptually, a D-Bus server is really trying to determine the credentials of (the process that initiated) a connection, not the credentials that the process had when it sent a particular message. Ideally, it does this with a getsockopt()-style API that queries the credentials of the connection's initiator without requiring any particular cooperation from that process, avoiding a class of possible failures. The leading '\0' in the D-Bus protocol is primarily a workaround for platforms where the message-based credentials-passing API is strictly better than the getsockopt()-style API (for example, on FreeBSD, SCM_CREDS includes a process ID but getpeereid() does not), or where the getsockopt()-style API does not exist at all. As a result libdbus, the reference implementation of D-Bus, does not implement Linux SCM_CREDENTIALS at all - it has no reason to do so, because the SO_PEERCRED socket option is equally informative. This change makes GDBusServer on Linux more closely match the behaviour of libdbus. In particular, GNOME/glib#1831 indicates that when a libdbus client connects to a GDBus server, recvmsg() sometimes yields a SCM_CREDENTIALS message with cmsg_data={pid=0, uid=65534, gid=65534}. I think this is most likely a race condition in the early steps to connect: client server connect accept send '\0' <- race -> set SO_PASSCRED = 1 receive '\0' If the server wins the race: client server connect accept set SO_PASSCRED = 1 send '\0' receive '\0' then everything is fine. However, if the client wins the race: client server connect accept send '\0' set SO_PASSCRED = 1 receive '\0' then the kernel does not record credentials for the message containing '\0' (because SO_PASSCRED was 0 at the time). However, by the time the server receives the message, the kernel knows that credentials are desired. I would have expected the kernel to omit the credentials header in this case, but it seems that instead, it synthesizes a credentials structure with a dummy process ID 0, a dummy uid derived from /proc/sys/kernel/overflowuid and a dummy gid derived from /proc/sys/kernel/overflowgid. In an unconfigured GDBusServer, hitting this race condition results in falling back to DBUS_COOKIE_SHA1 authentication, which in practice usually succeeds in authenticating the peer's uid. However, we encourage AF_UNIX servers on Unix platforms to allow only EXTERNAL authentication as a security-hardening measure, because DBUS_COOKIE_SHA1 relies on a series of assumptions including a cryptographically strong PRNG and a shared home directory with no write access by others, which are not necessarily true for all operating systems and users. EXTERNAL authentication will fail if the server cannot determine the client's credentials. In particular, this caused a regression when CVE-2019-14822 was fixed in ibus, which appears to be resolved by this commit. Qt clients (which use libdbus) intermittently fail to connect to an ibus server (which uses GDBusServer), because ibus no longer allows DBUS_COOKIE_SHA1 authentication or non-matching uids. Signed-off-by: Simon McVittie <smcv@collabora.com> Closes: https://gitlab.gnome.org/GNOME/glib/issues/1831
* gcredentialsprivate: Document the various private macrosSimon McVittie2020-10-141-0/+59
| | | | Signed-off-by: Simon McVittie <smcv@collabora.com>
* Add back g_memmoverpm-build2020-10-141-2/+0
|
* Revert "gmain: Warn when g_source_remove() fails"rpm-build2020-10-141-2/+0
|
* 2.56.12.56.1Matthias Clasen2018-04-062-2/+22
|
* Updated Slovenian translationMatej Urbančič2018-03-271-790/+984
|
* Spell Portuguese month and weekday names in lowercasePiotr Drąg2018-03-271-16/+16
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=794686
* gpollfilemonitor: Fix use-after-free caused by leaking GSourceTing-Wei Lan2018-03-261-0/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=794528
* gthreadedresolver: Fix compilation with res_nclose() but no res_nquery()Sebastian2018-03-261-0/+4
| | | | | | | | Some very odd systems have the functions to initialise and destroy a struct __res_state, but apparently not to do a DNS query using it. Fix the compilation on those systems. https://bugzilla.gnome.org/show_bug.cgi?id=794606
* glib-mkenums: Don't go into an infinite loop trying to find a matching {Sam Spilsbury2018-03-211-0/+2
| | | | | | | If we reach EOF before this happens, error out as opposed to looping around forever. https://bugzilla.gnome.org/show_bug.cgi?id=794506
* glib-mkenums: Don't treat typedef enum _SomeIdentifier {} as syntax errorSam Spilsbury2018-03-211-1/+1
| | | | | | | | | Previously we were only detecting typedef\*senum\s*\{, which does not handle the case where there is an entifier for the enum itself but not the typedef. glib-mkenums would then attempt to read the next line looking for a matching {, but in vain. https://bugzilla.gnome.org/show_bug.cgi?id=794506
* Remove duplicated option in gio.xmlFrank Dana2018-03-211-4/+0
| | | | | | The gio(1) man page entry for the tree subcommand lists '-h' twice under its Options, because that flag was duplicated in the source xml. https://bugzilla.gnome.org/show_bug.cgi?id=794473
* Update Slovak translationDušan Kazik2018-03-171-618/+867
|
* Fix Visual Studio projectsChun-wei Fan2018-03-166-11/+16
| | | | | | | | | | We are transitioning to Meson for Visual Studio builds, but since the Visual Studio projects are still around, we ought to keep them up-to-date (and these projects are needed to build for Visual Studio 2008, at least for x64 builds). Adapt to the source additions and merges for building gio-querymodules.exe and gspawn-win[32|64]-helper-console.exe.
* gapplication: Tighten up application ID validationPhilip Withnall2018-03-132-53/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tighten up the validation of application IDs so they are always exactly D-Bus well-known names. This is a slight change to the accepted format, but since anyone using the API with an application ID which was previously valid, but which was not a valid D-Bus well-known name, would have received an error from D-Bus when their application tried to register on the bus, I think this break is acceptable. It will affect any applications which have application IDs which are not valid D-Bus well-known names, and which use the G_APPLICATION_NON_UNIQUE flag. From a quick search in Debian Codesearch, no C applications use that flag. Update the documentation to use the rules from the D-Bus specification, including the latest advice discouraging use of hyphens: https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus Update the tests: • Add the examples from the documentation to validate them. • Especially the venerable 7-zip.org example. • Move a couple of tests from expected-failure to expected-success: they are valid D-Bus well-known names even if they’re a bit weird. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=793400
* tests: Use modern test assertions in GApplication testPhilip Withnall2018-03-131-21/+21
| | | | | | | | | | This will make the assertion failure messages a little more useful, and prevent the assertions being compiled out with G_DISABLE_ASSERT. Introduces no functional changes. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=793400
* gobject_gdb.py: 'address' is a property of gdb.Value not a functionMichael Olbrich2018-03-131-1/+1
| | | | | | | 'address' started out as a function, but it was changed to a property before the gdb Python support was release with gdb 7.0. https://bugzilla.gnome.org/show_bug.cgi?id=794194
* gdatetime: Add missing #define WEEKDAY_FULL_IS_LOCALERafal Luzynski2018-03-131-0/+1
| | | | | | | One more #define WEEKDAY_FULL_IS_LOCALE was missing from the commit 12f11090dc1b6062f4a493d79b382714ebbdc413. https://bugzilla.gnome.org/show_bug.cgi?id=793578
* tests: Compare month names case-insensitivelyRafal Luzynski2018-03-131-1/+5
| | | | | | | | | | | | | | | This patch relaxes the comparison rules and allow the month names to be in a mixed case. Translators should be allowed to provide the month names in a different case (lower/upper case, not grammatical case) from the content of glibc because it is disputable at the moment whether the month names should follow the language rules strictly and be titlecased only if it is obligatory to titlecase them or they should be also titlecased in the standalone case. Hopefully in future a conversion specifier will be invented to control the upper/lower case individually. https://bugzilla.gnome.org/show_bug.cgi?id=793645
* tests: Update month namesRafal Luzynski2018-03-131-3/+3
| | | | | | | Update the abbreviated month names in the test to match the actual content of the translated *.po files for Greek and Lithuanian. https://bugzilla.gnome.org/show_bug.cgi?id=793645
* Updated Spanish translationDaniel Mustieles2018-03-131-69/+68
|
* 2.56.02.56.0Matthias Clasen2018-03-123-3/+52
|
* tests: Skip the gdatetime month names test when running uninstalledPhilip Withnall2018-03-121-0/+11
| | | | | | | | | It needs the translations to be installed. See the comment added to the code. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=794180
* tests: Ensure gettext strings are loaded in UTF-8 in gdatetime.cPhilip Withnall2018-03-121-0/+2
| | | | | | | | | | | | See the previous commit. By convention, GLib assumes strings loaded from gettext are always in UTF-8, but we do need to tell gettext this. In most other tests, it doesn’t matter; but in the gdatetime test, we test re-encoding month names from EUC-JP, so we need to ensure the translations start in UTF-8 correctly. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=793578
* gdatetime: Fix locale handling for nl_langinfo() callsPhilip Withnall2018-03-121-21/+30
| | | | | | | | | | | | | | | | | | | | | With the various macros we use to provide fallbacks for missing nl_langinfo() fields, the locale handling can become quite complex: nl_langinfo() returns strings encoded in the current locale, but C_() returns strings encoded in UTF-8 (by GLib convention — you do actually need to call bind_textdomain_codeset() to achieve this). There are various format specifiers, especially with the new %Ob, %OB, %Oh specifiers, which conditionally call nl_langinfo() or something based on C_(). This makes encoding handling difficult. Add additional macros which indicate whether the macros they’re paired with return something encoded in the current locale, or encoded in UTF-8. The user of the macro can then use these to work out whether to re-encode. Signed-off-by: Philip Withnall <withnall@endlessm.com> https://bugzilla.gnome.org/show_bug.cgi?id=793578
View Lorry Controller Status