1. 25 Nov, 2020 1 commit
  2. 24 Nov, 2020 2 commits
  3. 20 Nov, 2020 10 commits
  4. 18 Nov, 2020 1 commit
    • Philip Withnall's avatar
      tests: Improve validity of binary GDBusMessage parsing tests · f936bba0
      Philip Withnall authored
      These tests were originally written using the output directly from a
      fuzzer which had triggered the bugs we’re testing for. However, that
      means they’re liable to no longer test what they’re intended to test if
      the `GDBusMessage` parsing code is changed to (for example) check for
      certain errors earlier in future.
      
      It’s better to only have one invalidity in each binary blob, so change
      the test messages to all be valid apart from the specific thing they’re
      testing for.
      
      The changes were based on reading the D-Bus specification directly:
      https://dbus.freedesktop.org/doc/dbus-specification.html
      
      During these changes I found one problem in
      `test_message_parse_deep_header_nesting()` where it wasn’t actually
      nesting variants in the header deeply enough to trigger the bug it was
      supposed to be testing for. Fixed that.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <pwithnall@endlessos.org>
      
      Fixes: #1963
      f936bba0
  5. 17 Nov, 2020 3 commits
  6. 15 Nov, 2020 1 commit
  7. 14 Nov, 2020 6 commits
  8. 11 Nov, 2020 2 commits
  9. 06 Nov, 2020 1 commit
  10. 03 Nov, 2020 1 commit
    • Carlos Garnacho's avatar
      glocalfileinfo: Use a single timeout source at a time for hidden file cache · c1e0e6a0
      Carlos Garnacho authored
      As hidden file caches currently work, every look up on a directory caches
      its .hidden file contents, and sets a 5s timeout to prune the directory
      from the cache.
      
      This creates a problem for usecases like Tracker Miners, which is in the
      business of inspecting as many files as possible from as many directories
      as possible in the shortest time possible. One timeout is created for each
      directory, which possibly means gobbling thousands of entries in the hidden
      file cache. This adds as many GSources to the glib worker thread, with the
      involved CPU overhead in iterating those in its main context.
      
      To fix this, use a unique timeout that will keep running until the cache
      is empty. This will keep the overhead constant with many files/folders
      being queried.
      c1e0e6a0
  11. 02 Nov, 2020 1 commit
  12. 31 Oct, 2020 5 commits
  13. 28 Oct, 2020 4 commits
    • Michael Catanzaro's avatar
      gsocketclient: fix crash when async connection step fails · c2b8fa8a
      Michael Catanzaro authored
      This is a regression from !1686. The tmp_error is no longer valid after
      it is "considered" and cannot be used at this point. We should print the
      error earlier instead.
      
      Fixes #2233
      c2b8fa8a
    • Simon McVittie's avatar
      gio/tests/gdbus-peer: Exercise fds attached to a large message · e5cee9ce
      Simon McVittie authored
      This incidentally also exercises the intended pattern for sending fds in
      a D-Bus message: the fd list is meant to contain exactly those fds that
      are referenced by a handle (type 'h') in the body of the message, with
      numeric handle value n corresponding to g_unix_fd_list_peek_fds(...)[n].
      
      Being able to send and receive file descriptors that are not referenced by
      a handle (as in OpenFile here) is a quirk of the GDBus API, and while it's
      entirely possible in the wire protocol, other D-Bus implementations like
      libdbus and sd-bus typically don't provide APIs that make this possible.
      
      Reproduces: #2074Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      e5cee9ce
    • Simon McVittie's avatar
      gdbus: Document the intended semantics of handles and fds · fc1f4969
      Simon McVittie authored
      In the D-Bus wire protocol, the handle type (G_VARIANT_TYPE_HANDLE, h)
      is intended to be an index/pointer into the implementation's closest
      equivalent of GUnixFDList: its numeric value has no semantic meaning
      (in the same way that the numeric values of pointers have no semantic
      meaning), but a handle with value n acts as a reference to the nth fd
      in the fd list.
      
      GDBus provides a fairly direct mapping from the wire protocol to the
      C API, which makes it technically possible to attach and use fds
      without ever referring to them in the message body, and some
      GLib-centric D-Bus APIs rely on this.
      
      However, the other major implementations of D-Bus (libdbus and sd-bus)
      transparently replace file descriptors with handles when building
      messages, and transparently replace handles with file descriptors when
      parsing messages. This means they cannot implement D-Bus APIs that do
      not follow the conventional meaning of handles as indexes/pointers into
      an equivalent of GUnixFDList.
      
      For interoperability, we should encourage D-Bus API designers to follow
      the convention, even though code written against GDBus doesn't strictly
      need to do so.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      fc1f4969
    • Simon McVittie's avatar
      gdbus: Cope with sending fds in a message that takes multiple writes · 70279f84
      Simon McVittie authored
      Suppose we are sending a 5K message with fds (so data->blob points
      to 5K of data, data->blob_size is 5K, and fd_list is non-null), but
      the kernel is only accepting up to 4K with each sendmsg().
      
      The first time we get into write_message_continue_writing(),
      data->total_written will be 0. We will try to write the entire message,
      plus the attached file descriptors; or if the stream doesn't support
      fd-passing (not a socket), we need to fail with
      "Tried sending a file descriptor on unsupported stream".
      
      Because the kernel didn't accept the entire message, we come back in.
      This time, we won't enter the Unix-specific block that involves sending
      fds, because now data->total_written is 4K, and it would be wrong to try
      to attach the same fds again. However, we also need to avoid failing
      with "Tried sending a file descriptor on unsupported stream" in this
      case. We just want to write out the data of the rest of the message,
      starting from (blob + total_written) (in this exaple, the last 1K).
      
      Resolves: #2074Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      70279f84
  14. 26 Oct, 2020 2 commits