Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#47741 closed update (fixed)

dbus @1.8.16: update to 1.8.18

Reported by: Schamschula (Marius Schamschula) Owned by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Priority: Normal Milestone:
Component: ports Version: 2.3.3
Keywords: haspatch Cc: dbevans (David B. Evans), RJVB (René Bertin)
Port: dbus

Description

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)

Attachments (2)

Portfile-dbus.diff (806 bytes) - added by Schamschula (Marius Schamschula) 6 years ago.
patch-dbus-1.10.6.diff (2.8 KB) - added by dbevans (David B. Evans) 5 years ago.
Pat to update dbus to 1.10.6 disabling EXTERNAL authentication by default

Download all attachments as: .zip

Change History (18)

Changed 6 years ago by Schamschula (Marius Schamschula)

Attachment: Portfile-dbus.diff added

comment:1 Changed 6 years ago by 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.

comment:2 Changed 6 years ago by dbevans (David B. Evans)

Warning comment added to dbus port in r136403.

comment:3 Changed 6 years ago by dbevans (David B. Evans)

Cc: mcalhoun@… removed
Owner: changed from macports-tickets@… to mcalhoun@…

comment:4 Changed 6 years ago by dbevans (David B. Evans)

Cc: devans@… added

Cc Me!

comment:5 in reply to:  1 Changed 6 years ago by 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 ...

comment:6 Changed 6 years ago by 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.

comment:7 Changed 6 years ago by 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.

comment:8 in reply to:  6 Changed 6 years ago by 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.

comment:9 Changed 6 years ago by RJVB (René Bertin)

Cc: rjvbertin@… added

Cc Me!

comment:10 Changed 6 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

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

comment:11 Changed 6 years ago by 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.

comment:12 Changed 5 years ago by 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 the line

<auth>EXTERNAL</auth>

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.

Version 1, edited 5 years ago by dbevans (David B. Evans) (previous) (next) (diff)

Changed 5 years ago by dbevans (David B. Evans)

Attachment: patch-dbus-1.10.6.diff added

Pat to update dbus to 1.10.6 disabling EXTERNAL authentication by default

comment:13 Changed 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: fixed
Status: newclosed

Thanks for your work on this.
Fixed in r145393.

comment:14 Changed 5 years ago by 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)?

comment:15 in reply to:  14 Changed 5 years ago by 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.

comment:16 Changed 5 years ago by 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.

Note: See TracTickets for help on using tickets.