1. 12 Apr, 2012 2 commits
    • David Zeuthen's avatar
      Avoid using monotonic time in the DBUS_COOKIE_SHA1 authentication method · 87035143
      David Zeuthen authored
      When libdbus-1 moved to using monotonic time support for the
      DBUS_COOKIE_SHA1 authentication was broken, in particular
      interoperability with non-libdbus-1 implementations such as GDBus.
      
      The problem is that if monotonic clocks are available in the OS,
      _dbus_get_current_time() will not return the number of seconds since
      the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus
      specification. If both peers are using libdbus-1 it's not a problem
      since both ends will use the wrong time and thus agree. However, if
      the other end is another implementation and following the spec it will
      not work.
      
      First, we change _dbus_get_current_time() back so it always returns
      time since the Epoch and we then rename it _dbus_get_real_time() to
      make this clear. We then introduce _dbus_get_monotonic_time() and
      carefully make all current users of _dbus_get_current_time() use it,
      if applicable. During this audit, one of the callers,
      _dbus_generate_uuid(), was currently using monotonic time but it was
      decided to make it use real time instead.
      Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      Reviewed-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580
      87035143
    • David Zeuthen's avatar
      Avoid using monotonic time in the DBUS_COOKIE_SHA1 authentication method · 8734e4a1
      David Zeuthen authored
      When libdbus-1 moved to using monotonic time support for the
      DBUS_COOKIE_SHA1 authentication was broken, in particular
      interoperability with non-libdbus-1 implementations such as GDBus.
      
      The problem is that if monotonic clocks are available in the OS,
      _dbus_get_current_time() will not return the number of seconds since
      the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus
      specification. If both peers are using libdbus-1 it's not a problem
      since both ends will use the wrong time and thus agree. However, if
      the other end is another implementation and following the spec it will
      not work.
      
      First, we change _dbus_get_current_time() back so it always returns
      time since the Epoch and we then rename it _dbus_get_real_time() to
      make this clear. We then introduce _dbus_get_monotonic_time() and
      carefully make all current users of _dbus_get_current_time() use it,
      if applicable. During this audit, one of the callers,
      _dbus_generate_uuid(), was currently using monotonic time but it was
      decided to make it use real time instead.
      Signed-off-by: default avatarDavid Zeuthen <davidz@redhat.com>
      Reviewed-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580
      8734e4a1
  2. 22 Mar, 2012 2 commits
  3. 04 Mar, 2012 2 commits
  4. 21 Feb, 2012 1 commit
  5. 13 Feb, 2012 3 commits
  6. 10 Feb, 2012 1 commit
  7. 08 Feb, 2012 1 commit
  8. 07 Feb, 2012 1 commit
  9. 23 Jan, 2012 2 commits
  10. 04 Jan, 2012 3 commits
  11. 21 Nov, 2011 2 commits
  12. 28 Sep, 2011 1 commit
    • Simon McVittie's avatar
      Merge tests' cmake and autotools bus configuration · e9f0378b
      Simon McVittie authored
      In Unix, the tests listened on both debug-pipe (which is a socketpair,
      or a TCP emulation of socketpair on Windows) and a Unix socket.
      
      In the Windows port, the tests were hard-coded to listen on a particular
      port, which allowed the dispatch test to connect to that port, as long
      as no two tests ran simultaneously (which I don't think was ever guaranteed -
      make -j can violate this). That's valid out-of-process, and also
      fully-specified, so they only needed one <listen> directive, so the
      CMake input only had one.
      
      To make the tests work under CMake on Unix, there was a hack: the string
      substituted for the content of the <listen> directive contained
      </listen><listen> to get the other address in, which is pretty nasty.
      
      Instead of doing that, I've made both build systems, on both Unix and
      Windows, use both debug-pipe and a more normal transport (Unix or TCP).
      debug-pipe has a Windows implementation and it's used in
      dbus-spawn-win.c, so it'd better work. The use of debug-pipe is now
      hard-coded rather than being a configure parameter (there's no reason
      to vary it in different builds), and I used TEST_LISTEN as the name of the
      Unix/TCP address, because it's a "vague" address (no specific Unix path, no
      TCP port), that you can listen on but not connect to.
      
      This in turn means that we can merge the Autoconf .in and CMake .cmake
      files, similar to Bug #41033.
      
      You might wonder why I've kept debug-pipe. I did try to get rid of it, but
      it turns out that the tests in dispatch.c rely on
      dbus_connection_open_private() not blocking, and normal socket
      connections block on connect(). Until we fix that by adding an async
      version of dbus_connection_open_private(), it won't be safe to have a
      test like dispatch.c that "talks to itself", unless it uses a transport
      as trivial as debug-pipe in which neither end has to block on the other.
      Signed-off-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Ralf Habacker's avatarRalf Habacker <ralf.habacker@freenet.de>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41222
      e9f0378b
  13. 21 Sep, 2011 3 commits
  14. 19 Sep, 2011 9 commits
  15. 26 Aug, 2011 1 commit
  16. 13 Aug, 2011 1 commit
  17. 11 Aug, 2011 1 commit
  18. 05 Aug, 2011 4 commits