Commit Graph

22377 Commits

Author SHA1 Message Date
Goran Vidović
284b7eb7f2 Update Croatian translation 2021-10-27 17:16:17 +00:00
Philip Withnall
dde05fd4fc 2.66.8
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2.66.8
2021-03-18 13:45:48 +00:00
Sebastian Dröge
b954bc1c70 Merge branch 'backport-1976-win32-dir-permissions-2-66' into 'glib-2-66'
Backport !1976 “Use the right permissions for directory watching on Win32” to glib-2-66

See merge request GNOME/glib!1990
2021-03-14 15:03:50 +00:00
Luca Bacci
9205e4205b Use the right permissions for directory watching on Win32
Using FILE_GENERIC_READ | FILE_GENERIC_WRITE access rights for directory monitoring
might cause problems, as noted in https://gitlab.gnome.org/GNOME/gimp/-/issues/4594.

ReadDirectoryChanges only needs FILE_LIST_DIRECTORY, so use that.

Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/4594
2021-03-14 13:09:06 +00:00
Philip Withnall
01c5468e10 Merge branch 'backport-2325-symlink-replace-file-glib-2-66' into 'glib-2-66'
Backport !2325 “file-roller symlink attack” to glib-2-66

See merge request GNOME/glib!1982
2021-03-10 19:07:50 +00:00
Philip Withnall
6c6439261b glocalfileoutputstream: Add a missing O_CLOEXEC flag to replace()
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-03-10 17:57:31 +00:00
Philip Withnall
317b3b5870 glocalfileoutputstream: Fix CREATE_REPLACE_DESTINATION with symlinks
The `G_FILE_CREATE_REPLACE_DESTINATION` flag is equivalent to unlinking
the destination file and re-creating it from scratch. That did
previously work, but in the process the code would call `open(O_CREAT)`
on the file. If the file was a dangling symlink, this would create the
destination file (empty). That’s not an intended side-effect, and has
security implications if the symlink is controlled by a lower-privileged
process.

Fix that by not opening the destination file if it’s a symlink, and
adjusting the rest of the code to cope with
 - the fact that `fd == -1` is not an error iff `is_symlink` is true,
 - and that `original_stat` will contain the `lstat()` results for the
   symlink now, rather than the `stat()` results for its target (again,
   iff `is_symlink` is true).

This means that the target of the dangling symlink is no longer created,
which was the bug. The symlink itself continues to be replaced (as
before) with the new file — this is the intended behaviour of
`g_file_replace()`.

The behaviour for non-symlink cases, or cases where the symlink was not
dangling, should be unchanged.

Includes a unit test.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Fixes: #2325
2021-03-10 17:57:31 +00:00
Philip Withnall
ce0eb088a6 glocalfileoutputstream: Factor out a flag check
This clarifies the code a little. It introduces no functional changes.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-03-10 17:57:31 +00:00
Philip Withnall
32d3d02a50 tests: Stop using g_test_bug_base() in file tests
Since a following commit is going to add a new test which references
Gitlab, so it’s best to move the URI bases inside the test cases.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-03-10 17:57:31 +00:00
Philip Withnall
78420a75ae glocalfileoutputstream: Fix a typo in a comment
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-03-10 17:57:31 +00:00
Philip Withnall
95115f029d 2.66.7
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2.66.7
2021-02-11 12:22:39 +00:00
Simon McVittie
bd48718f09 Merge branch 'backport-1934-dbus-flags-glib-2-66' into 'glib-2-66'
Backport !1934 “gdbus: Reject attempts to set future connection or server flags” to glib-2-66

See merge request GNOME/glib!1945
2021-02-11 12:12:36 +00:00
Simon McVittie
a5b223595a gdbus: Reject attempts to set future connection or server flags
The GDBusConnectionFlags and GDBusServerFlags can affect how we carry
out authentication and authorization, either making it more or less
restrictive, so it's desirable to "fail closed" if a program is compiled
against a new version of GLib but run against an old version.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2021-02-11 11:54:30 +00:00
Sebastian Dröge
8670c78dab Merge branch 'backport-1942-bytes-byte-array-bitten-glib-2-66' into 'glib-2-66'
Backport !1942 “gbytearray: Do not accept too large byte arrays” to glib-2-66

See merge request GNOME/glib!1944
2021-02-11 11:24:09 +00:00
Krzesimir Nowak
0f384c88a2 gbytearray: Do not accept too large byte arrays
GByteArray uses guint for storing the length of the byte array, but it
also has a constructor (g_byte_array_new_take) that takes length as a
gsize. gsize may be larger than guint (64 bits for gsize vs 32 bits
for guint). It is possible to call the function with a value greater
than G_MAXUINT, which will result in silent length truncation. This
may happen as a result of unreffing GBytes into GByteArray, so rather
be loud about it.

(Test case tweaked by Philip Withnall.)

(Backport 2.66: Add #include gstrfuncsprivate.h in the test case for
`g_memdup2()`.)
2021-02-11 11:10:55 +00:00
Sebastian Dröge
b34d68b672 Merge branch 'backport-1941-keyfile-fix-again-glib-2-66' into 'glib-2-66'
Backport !1941 “gkeyfilesettingsbackend: Fix basename handling when group is unset” to glib-2-66

See merge request GNOME/glib!1943
2021-02-11 09:28:09 +00:00
Philip Withnall
221c266853 tests: Add tests for key name handling in the keyfile backend
This tests the two recent commits.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-02-11 09:13:14 +00:00
Philip Withnall
31e0d403ba gkeyfilesettingsbackend: Disallow empty key or group names
These should never have been allowed; they will result in precondition
failures from the `GKeyFile` later on in the code.

A test will be added for this shortly.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-02-11 09:13:14 +00:00
Philip Withnall
cb9ee701ef gkeyfilesettingsbackend: Fix basename handling when group is unset
Fix an effective regression in commit
7781a9cbd2, which happens when
`convert_path()` is called with a `key` which contains no slashes. In
that case, the `key` is entirely the `basename`.

Prior to commit 7781a9cb, the code worked through a fluke of `i == -1`
cancelling out with the various additions in the `g_memdup()` call, and
effectively resulting in `g_strdup (key)`.

Spotted by Guido Berhoerster.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-02-11 09:13:14 +00:00
Sebastian Dröge
00b181fa84 Merge branch 'wip/issue2323-2-66' into 'glib-2-66'
[2.66] Fix regressions in 2.66.6 where negative gssize indicates strlen()

See merge request GNOME/glib!1933
2021-02-08 11:32:07 +00:00
Simon McVittie
3d1550354c tls-interaction: Add test coverage for various ways to set the password
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit df4501316c)
2021-02-08 11:10:33 +00:00
Simon McVittie
4506d1859a gtlspassword: Fix inverted assertion
The intention here was to assert that the length of the password fits
in a gssize. Passwords more than half the size of virtual memory are
probably excessive.

Fixes: a8b204ff "gtlspassword: Forbid very long TLS passwords"
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 61bb52ec42)
2021-02-08 11:10:32 +00:00
Simon McVittie
d9db1faac5 io-channel test: Add coverage for g_io_channel_set_line_term(., ., -1)
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 63f37f8c3b)
2021-02-08 11:10:30 +00:00
Simon McVittie
e069c50467 giochannel: Don't store negative line_term_len in GIOChannel struct
Adding test coverage indicated that this was another bug in 0cc11f74.

Fixes: 0cc11f74 "giochannel: Forbid very long line terminator strings"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2323
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 5dc8b0014c)
2021-02-08 11:10:29 +00:00
Jan Alexander Steffens (heftig)
f8273b9ade giochannel: Fix length_size bounds check
The inverted condition is an obvious error introduced by ecdf91400e.

Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2323

(cherry picked from commit a149bf2f90)
2021-02-08 11:10:28 +00:00
Philip Withnall
d5ec4f360f 2.66.6
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2.66.6
2021-02-04 18:20:43 +00:00
Philip Withnall
e8fe1d51fe Merge branch 'backport-1926-memdup-glib-2-66' into 'glib-2-66'
Backport !1926 “Add g_memdup2()” to glib-2-66

See merge request GNOME/glib!1927
2021-02-04 18:08:14 +00:00
Philip Withnall
ecdf91400e giochannel: Forbid very long line terminator strings
The public API `GIOChannel.line_term_len` is only a `guint`. Ensure that
nul-terminated strings passed to `g_io_channel_set_line_term()` can’t
exceed that length. Use `g_memdup2()` to avoid a warning (`g_memdup()`
is due to be deprecated), but not to avoid a bug, since it’s also
limited to `G_MAXUINT`.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
2021-02-04 17:51:01 +00:00
Philip Withnall
777b95a88f gtlspassword: Forbid very long TLS passwords
The public API `g_tls_password_set_value_full()` (and the vfunc it
invokes) can only accept a `gssize` length. Ensure that nul-terminated
strings passed to `g_tls_password_set_value()` can’t exceed that length.
Use `g_memdup2()` to avoid an overflow if they’re longer than
`G_MAXUINT` similarly.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
2021-02-04 17:51:01 +00:00
Philip Withnall
65ec7f4d6e gsocket: Use gsize to track native sockaddr’s size
Don’t use an `int`, that’s potentially too small. In practical terms,
this is not a problem, since no socket address is going to be that big.

By making these changes we can use `g_memdup2()` without warnings,
though. Fewer warnings is good.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
2021-02-04 17:51:01 +00:00
Philip Withnall
ba8ca44305 gkeyfilesettingsbackend: Handle long keys when converting paths
Previously, the code in `convert_path()` could not handle keys longer
than `G_MAXINT`, and would overflow if that was exceeded.

Convert the code to use `gsize` and `g_memdup2()` throughout, and
change from identifying the position of the final slash in the string
using a signed offset `i`, to using a pointer to the character (and
`strrchr()`). This allows the slash to be at any position in a
`G_MAXSIZE`-long string, without sacrificing a bit of the offset for
indicating whether a slash was found.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
2021-02-04 17:51:01 +00:00
Philip Withnall
2aaf593a9e gwin32: Use gsize internally in g_wcsdup()
This allows it to handle strings up to length `G_MAXSIZE` — previously
it would overflow with such strings.

Update the several copies of it identically.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
2021-02-04 17:51:01 +00:00
Philip Withnall
f9ee2275cb gdatainputstream: Handle stop_chars_len internally as gsize
Previously it was handled as a `gssize`, which meant that if the
`stop_chars` string was longer than `G_MAXSSIZE` there would be an
overflow.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
2021-02-04 17:51:01 +00:00
Philip Withnall
0cbad67321 gwinhttpfile: Avoid arithmetic overflow when calculating a size
The members of `URL_COMPONENTS` (`winhttp_file->url`) are `DWORD`s, i.e.
32-bit unsigned integers. Adding to and multiplying them may cause them
to overflow the unsigned integer bounds, even if the result is passed to
`g_memdup2()` which accepts a `gsize`.

Cast the `URL_COMPONENTS` members to `gsize` first to ensure that the
arithmetic is done in terms of `gsize`s rather than unsigned integers.

Spotted by Sebastian Dröge.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
2021-02-04 17:51:01 +00:00
Philip Withnall
0736b7c1e7 glib: Use g_memdup2() instead of g_memdup() in obvious places
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 by GHSL team member Kevin Backhouse.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: GHSL-2021-045
Helps: #2319
2021-02-04 17:51:01 +00:00
Philip Withnall
6110caea45 gobject: Use g_memdup2() instead of g_memdup() in obvious places
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
2021-02-04 17:51:01 +00:00
Philip Withnall
be8834340a gio: Use g_memdup2() instead of g_memdup() in obvious places
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
2021-02-04 17:51:01 +00:00
Philip Withnall
5e5f75a77e gstrfuncs: Add internal g_memdup2() function
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: GHSL-2021-045
Helps: #2319
2021-02-04 17:06:04 +00:00
Philip Withnall
79c5866d31 2.66.5
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2.66.5
2021-02-03 15:27:28 +00:00
Simon McVittie
0051c06355 Merge branch 'backport-1920-setgid-dbus-session-glib-2-66' into 'glib-2-66'
Backport !1920 “Resolve GDBus regressions in setcap/setgid programs” to glib-2-66

See merge request GNOME/glib!1922
2021-02-03 12:07:51 +00:00
Simon McVittie
3f11992875 gdbus: Use DBUS_SESSION_BUS_ADDRESS if AT_SECURE but not setuid
This is against my better judgement, but it's the least bad regression
fix I can think of. If we don't do this, at least gnome-keyring-daemon
(setcap) and msmtp (setgid) are known to regress.

Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2305
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981420
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981555
Signed-off-by: Simon McVittie <smcv@collabora.com>
2021-02-03 11:49:45 +00:00
Simon McVittie
375cbee175 gdbus: Rename a variable to be less misleading
We're using "setuid" here as shorthand for any elevated privileges
that should make us distrust the caller: setuid, setgid, filesystem
capabilities, more obscure Linux things that set the AT_SECURE flag
(such as certain AppArmor transitions), and their equivalents on
other operating systems. This is fine if we do it consistently, but
I'm about to add a check for whether we are *literally* setuid,
which would be particularly confusing without a rename.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2021-02-03 11:49:45 +00:00
Simon McVittie
72eadbde6b gdbus: Improve readability by avoiding ternary operator
Signed-off-by: Simon McVittie <smcv@collabora.com>
2021-02-03 11:49:45 +00:00
Sebastian Dröge
894396dc45 Merge branch 'backport-1902-spawn-path-fix-glib-2-66' into 'glib-2-66'
Backport !1902 “spawn: Don't set a search path if we don't want to search PATH” to glib-2-66

See merge request GNOME/glib!1913
2021-02-02 10:48:31 +00:00
Simon McVittie
9eb4fe3c00 Expand test coverage for G_SPAWN_SEARCH_PATH
Signed-off-by: Simon McVittie <smcv@collabora.com>
2021-02-01 12:00:05 +00:00
Thomas Haller
8a3c3b8cd9 spawn: prefer allocating buffers on stack for small sizes to avoid valgrind leaks
We preallocate buffers that are used after forked. That is because
malloc()/free() are not async-signal-safe and must not be used between
fork() and exec().

However, for the child process that exits without fork, valgrind wrongly
reports these buffers as leaked.
That can be suppressed with "--child-silent-after-fork=yes", but it is
cumbersome.

Work around by trying to allocate the buffers on the stack. At
least in the common cases where the pointers are small enough
so that we can reasonably do that.

If the buffers happen to be large, we still allocate them on the heap
and the problem still happens. Maybe we could have also allocated them
as thread_local, but currently glib doesn't use that.

[smcv: Cosmetic adjustments to address review comments from pwithnall]
2021-02-01 12:00:05 +00:00
Simon McVittie
136a9d7ffd Add test coverage for G_SPAWN_SEARCH_PATH
For manual test coverage that would reproduce the bug fixed in !1902,
copy /bin/true (or any other harmless executable) to
/usr/bin/spawn-test-helper.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2021-02-01 12:00:05 +00:00
Simon McVittie
0d50c6bbe6 spawn: Don't set a search path if we don't want to search PATH
do_exec() and g_execute() rely on being passed a NULL search path
if we intend to avoid searching the PATH, but since the refactoring
in commit 62ce66d4, this was never done. This resulted in some spawn
calls searching the PATH when it was not intended.

Spawn calls that go through the posix_spawn fast-path were unaffected.

The deprecated gtester utility, as used in GTK 3, relies on the
ability to run an executable from the current working directory by
omitting the G_SPAWN_SEARCH_PATH flag. This *mostly* worked, because
our fallback PATH ends with ".". However, if an executable of the
same name existed in /usr/bin or /bin, it would run that instead of the
intended test: in particular, GTK 3's build-time tests failed if
ImageMagick happens to be installed, because gtester would accidentally
run display(1) instead of testsuite/gdk/display.

Fixes: 62ce66d4 "gspawn: Don’t use getenv() in async-signal-safe context"
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977961
2021-02-01 12:00:05 +00:00
Emmanuele Bassi
872181c4f8 Merge branch 'backport-1868-desktop-parsing-glib-2-66' into 'glib-2-66'
Backport !1868 “gdesktopappinfo: Fix validation of XDG_CURRENT_DESKTOP” to glib-2-66

See merge request GNOME/glib!1872
2021-01-11 12:30:32 +00:00
Krzesimir Nowak
4963b48a84 tests: Update the expected count in file test
We added another desktop file, so update the file count.
2021-01-11 12:04:00 +00:00