dbus @1.8.16: update to 1.8.18

[Schamschula (Marius Schamschula)]

dbus has ben updated to version 1.8.18:

The “unicorn rifts” release.

Security hardening:

• On Unix platforms, change the default configuration for the session bus
  to only allow EXTERNAL authentication (secure kernel-mediated
  credentials-passing), as was already done for the system bus.

  This avoids falling back to DBUS_COOKIE_SHA1, which relies on strongly
  unpredictable pseudo-random numbers; under certain circumstances
  (/dev/urandom unreadable or malloc() returns NULL), dbus could
  fall back to using rand(), which does not have the desired unpredictability.
  The fallback to rand() has not been changed in this stable-branch since
  the necessary code changes for correct error-handling are rather intrusive.

  If you are using D-Bus over the (unencrypted!) tcp: or nonce-tcp: transport,
  in conjunction with DBUS_COOKIE_SHA1 and a shared home directory using
  NFS or similar, you will need to reconfigure the session bus to accept
  DBUS_COOKIE_SHA1 by commenting out the <auth> element. This configuration
  is not recommended.

  (fd.o #90414, Simon McVittie)

Other fixes:

• Add locking to DBusCounter's reference count and notify function
  (fd.o #89297, Adrian Szyndela)

• Ensure that DBusTransport's reference count is protected by the
  corresponding DBusConnection's lock (fd.o #90312, Adrian Szyndela)

• On Windows, listen on the same port for IPv4 and IPv6 (previously
  broken by an endianness mistake), and fix a failure to bind TCP
  sockets on approximately 1 attempt in 256 (fd.o #87999, Ralf Habacker)

• Correctly release DBusServer mutex before early-return if we run out
  of memory while copying authentication mechanisms (fd.o #90021,
  Ralf Habacker)

• Correctly initialize all fields of DBusTypeReader (fd.o #90021;
  Ralf Habacker, Simon McVittie)

• Fix some missing \n in verbose (debug log) messages (fd.o #90004,
  Ralf Habacker)

• Clean up some memory leaks in test code (fd.o #90021, Ralf Habacker)

[dbevans (David B. Evans)]

Please hold off on this update for now.

The security hardening of the session daemon causes GNOME 3 applications that rely on dbus to fail. This needs to be worked out before updating.

Thanks.

[dbevans (David B. Evans)]

Warning comment added to dbus port in r136403.

[dbevans (David B. Evans)]

Cc Me!

[RJVB (René Bertin)]

Replying to devans@…:

Please hold off on this update for now.

The security hardening of the session daemon causes GNOME 3 applications that rely on dbus to fail. This needs to be worked out before updating.

Is that only an issue on OS X / with MacPorts? What's its status? FWIW, dbus was just updated to 1.8.20, with the next stable release (1.10.0 IIRC) scheduled to follow soon ...

[dbevans (David B. Evans)]

I haven't had time to test 1.8.20 (on my list) but 1.8.18 still breaks glib2's GDBus API relied upon by most GNOME-3 apps.

Current version 1.18.16 works fine.

While there hasn't been a lot of visible activity, I am working on this. Please have some patience. We need to resist the urge to upgrade ports without considering the impact on their dependents. That is, we need to wait for upstream developers to support the newer versions before we make the change ourselves.

[dbevans (David B. Evans)]

Will update this ticket after testing/debugging with the latest GNOME 3.17.4 unstable release. If you want to do some testing yourself, I have test ports of the latest available GNOME unstable release at ​https://trac.macports.org/browser/users/devans/GNOME-3/unstable/dports.

Most of the 3.17.4 release is there already although the final BOM hasn't been released as yet. Official release date is tomorrow.

[RJVB (René Bertin)]

Replying to devans@…:

I haven't had time to test 1.8.20 (on my list) but 1.8.18 still breaks glib2's GDBus API relied upon by most GNOME-3 apps.

Current version 1.18.16 works fine.

Please have some patience. We need to resist the urge to upgrade ports without considering the impact on their dependents.

Amen to that! I don't actually have any urge to update the gnome apps I use (they mostly work fine and I cannot say I'm very happy with the direction the newer gnome apps are moving in). So yeah, I'm hoping that an upcoming DBus version unbreaks what 1.8.18 broke, or maybe that an update to glib2 will fix its GDBus API.

[RJVB (René Bertin)]

Cc Me!

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I would like to update dbus to 1.10.6.
Is compatibility still a concern?

[dbevans (David B. Evans)]

I did some testing with 1.10.6 last night and ran into some issues. Not all GNOME apps I tested were effected but others were. Going to bed now but will try and post some test cases tomorrow or Monday. Perhaps you can see what the problem is. I'd like to get this updated as well.

[dbevans (David B. Evans)]

Actually all apps were effected if I reloaded (launchdctl unload/load) when changing version.

But after a lot of head scratching, I finally came up with an answer to what's going on.

First an example using eog:

Running dbus 1.8.16 eog emits no warning/error messages to the console. However, if I install 1.10.6, I get the following:

$ eog
** (eog:92151): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.a11y.Bus exited with status 1

(eog:92151): dconf-WARNING **: failed to commit changes to dconf: Exhausted all available authentication mechanisms (tried: EXTERNAL, DBUS_COOKIE_SHA1, ANONYMOUS) (available: EXTERNAL, DBUS_COOKIE_SHA1, ANONYMOUS)

(eog:92151): dconf-WARNING **: failed to commit changes to dconf: Exhausted all available authentication mechanisms (tried: EXTERNAL, DBUS_COOKIE_SHA1, ANONYMOUS) (available: EXTERNAL, DBUS_COOKIE_SHA1, ANONYMOUS)

All 3 of these are the result of attempts to access the session dbus that fail due to authentication issues.

The key to the problem is the word EXTERNAL. I finally figured out that the default session.conf file now contains the following:

<!-- On Unix systems, the most secure authentication mechanism is
  EXTERNAL, which uses credential-passing over Unix sockets.

  This authentication mechanism is not available on Windows,
  is not suitable for use with the tcp: or nonce-tcp: transports,
  and will not work on obscure flavours of Unix that do not have
  a supported credentials-passing mechanism. On those platforms/transports,
  comment out the <auth> element to allow fallback to DBUS_COOKIE_SHA1. -->
  <auth>EXTERNAL</auth>

When this authentication method is specified, dbus expects any client to authenticate using an appropriate protocol over the dbus socket. eog does not do this. In fact, I haven't found ANY app let alone any GNOME app that does. So this is a show stopper for most apps attempting to access the session bus.

Commenting out this line as suggested in the comments restores the previous (successful) dbus behavior. (Don't forget to unload/load again).

The value of this line (whether it is commented out or not) is accomplished by setting the substitution variable DBUS_SESSION_CONF_MAYBE_AUTH_EXTERNAL during configuration. Attached is a patch that updates port dbus to 1.10.6 using an updated patch-configure.diff that diables EXTERNAL authentication by default on darwin platforms.

Using the updated 1.10.6 port, apps using the session dbus run as expected out of the box (for me at least).

Sorry it took me so long to tumble to what was going on.

[dbevans (David B. Evans)]

Pat to update dbus to 1.10.6 disabling EXTERNAL authentication by default

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Thanks for your work on this.
Fixed in r145393.

[RJVB (René Bertin)]

So what exactly does this update fix (that wasn't broken) or what new indispensable features does it add other than "security hardening" which apparently has to be turned off?

I use a few applications (with a whole slew of background helpers; Kontact/KMail) that rely heavily on DBus that I cannot allow to be broken so I'm very reluctant to upgrade matters just for upgrading's sake.

More importantly, is it possible to update this port without having to log off and back in immediately (which is about the only reliable way I have found to restart the session DBus daemon and let everything continue to work)?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to rjvbertin@…:

So what exactly does this update fix (that wasn't broken) or what new indispensable features does it add other than "security hardening" which apparently has to be turned off?

There is file called NEWS in the source files that might be of help.

I use a few applications (with a whole slew of background helpers; Kontact/KMail) that rely heavily on DBus that I cannot allow to be broken so I'm very reluctant to upgrade matters just for upgrading's sake.

There are a couple of options here.
You can create a ​local repository with the older version until you are confident with the new version.
If at all possible, however, it would be nice to get the newer version of dbus working on your system so everyone can benefit from the improvements.

More importantly, is it possible to update this port without having to log off and back in immediately (which is about the only reliable way I have found to restart the session DBus daemon and let everything continue to work)?

I am not sure if this is the best way, but

sudo launchctl unload  /Library/LaunchDaemons/org.freedesktop.dbus-system.plist
sudo launchctl load -w /Library/LaunchDaemons/org.freedesktop.dbus-system.plist

launchctl unload  /Library/LaunchAgents/org.freedesktop.dbus-session.plist
launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist

has worked for me.

[RJVB (René Bertin)]

If at all possible, however, it would be nice to get the newer version of dbus working on your system so everyone can benefit from the improvements.

Everyone as in me, myself and I? :)

I'm surprised to see you're running a system dbus session, I was under the impression that wasn't required (and/or didn't work). I'm pretty sure I have already tried launchctl to relaunch the dbus daemon, but IIRC there were always issues in which all applications didn't get the correct new socket address. It'd be nice if that socket address could be consistent across invocations, but that's probably a topic for upstream.