dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2018-10-15T13:43:54Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/165Mismatch in documentation of dbus-send parameter --bus, --peer and --address2018-10-15T13:43:54ZBugzilla Migration UserMismatch in documentation of dbus-send parameter --bus, --peer and --address## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99808)](https://bugs.freedesktop.org/show_bug.cgi?id=99808)**
## Description
dbus-send command line help prints
Usage: dbus-s...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99808)](https://bugs.freedesktop.org/show_bug.cgi?id=99808)**
## Description
dbus-send command line help prints
Usage: dbus-send [--help] [--system | --session | --bus=ADDRESS | --peer=ADDRESS] [--dest=NAME] [--type=TYPE] [--print-reply[=literal]] [--reply-timeout=MSEC] `<destination object path>` `<message name>` [contents ...]
while the man page prints out
dbus-send [--system | --session | --address=ADDRESS] [--dest=NAME] [--print-reply [=literal]] [--reply-timeout=MSEC] [--type=TYPE] OBJECT_PATH INTERFACE.MEMBER [CONTENTS...]
....
--address=ADDRESS
Send to ADDRESS.
It differs in the parameter --bus, --address and --peer.
Looking at the implementation of dbus-send there are all mentioned parameters supported:
if ((strstr (arg, "--bus=") == arg) || (strstr (arg, "--peer=") == arg) || (strstr (arg, "--address=") == arg))
{
if (arg[2] == 'b') /* bus */
{
is_bus = TRUE;
}
else if (arg[2] == 'p') /* peer */
{
is_bus = FALSE;
}
else /* address; keeping backwards compatibility */
{
is_bus = FALSE;
}
address = strchr (arg, '=') + 1;
if (address[0] == '\0')
{
fprintf (stderr, "\"--peer=\" and \"--bus=\" require an ADDRESS\n");
usage (1);
}
except that --address looks to be outdated and could not be used to connect to a bus. In the opposite dbus-monitor provides connecting to a bus using --address.
Version: 1.10https://gitlab.freedesktop.org/dbus/dbus/-/issues/164Shut down autolaunched Windows session bus after disconnecting last client2022-05-03T06:25:24ZBugzilla Migration UserShut down autolaunched Windows session bus after disconnecting last client## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99751)](https://bugs.freedesktop.org/show_bug.cgi?id=99751)**
## Description
DBus on windows auto by default starts dbus daemon...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99751)](https://bugs.freedesktop.org/show_bug.cgi?id=99751)**
## Description
DBus on windows auto by default starts dbus daemon only on demand. If a client tries to connect to the session bus using the autolaunch meta protocol dbus library starts a dbus session daemon by default.
Unfortunally if the last clients disconnects dbus-daemon is still running which is an issue for example in case the application has been started from an external drive or usb stick.
There should be a dbus daemon configuration option to let the daemon shutdown itself after a timeout in case last client has been disconnected.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/163Add dbus verbose channels to verbose output.2018-10-15T13:44:36ZBugzilla Migration UserAdd dbus verbose channels to verbose output.## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99585)](https://bugs.freedesktop.org/show_bug.cgi?id=99585)**
## Description
Dbus verbose messages are spread all over the dbus...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99585)](https://bugs.freedesktop.org/show_bug.cgi?id=99585)**
## Description
Dbus verbose messages are spread all over the dbus code and prints out
internal informations helping to find issues. Caused by the amount of
generated messages it is partially hard to follow messages from special
categories which is provided by this patch.
DBus verbose channels are special keywords which are defined on file level
and are print out on each _dbus_verbose() call which makes it possible
to filter out unrelated messages.
DBus verbose channels are enabled by adding the following code fragment
...
DBUS_VERBOSE_CHANNEL(`<category>`)
in a file before using any dbus_verbose () calls.
In case someone do not want to have the keyword in each verbose message,
it would be possible to extend DBUS_VERBOSE environment variable parsing
to support filtering verbose categories by specifing DBUS_VERBOSE=`<category>`.https://gitlab.freedesktop.org/dbus/dbus/-/issues/162Missing dbus daemon auth config test coverage2018-10-15T13:44:45ZBugzilla Migration UserMissing dbus daemon auth config test coverage## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99512)](https://bugs.freedesktop.org/show_bug.cgi?id=99512)**
## Description
While working on [bug 96577](https://bugs.freedesk...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99512)](https://bugs.freedesktop.org/show_bug.cgi?id=99512)**
## Description
While working on [bug 96577](https://bugs.freedesktop.org/show_bug.cgi?id=96577) issues with dbus daemon auth config implementation has been detected and therefore it would be nice to have a easy to run test case to ensure that changes in the auth (and config) implementation of dbus daemon do not introduce regressions.
Version: 1.10
### Depends on
* [Bug 99621](https://bugs.freedesktop.org/show_bug.cgi?id=99621)
* [Bug 99622](https://bugs.freedesktop.org/show_bug.cgi?id=99622)
### Blocking
* [Bug 96577](https://bugs.freedesktop.org/show_bug.cgi?id=96577)https://gitlab.freedesktop.org/dbus/dbus/-/issues/161dbus-monitor: optionally print monotonic timestamps in Linux kernel style2018-10-15T13:45:03ZBugzilla Migration Userdbus-monitor: optionally print monotonic timestamps in Linux kernel style## Submitted by Mikhail Durnev
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98898)](https://bugs.freedesktop.org/show_bug.cgi?id=98898)**
## Description
Created attachment 128263
Add timestamps to dbus-monitor logs
...## Submitted by Mikhail Durnev
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98898)](https://bugs.freedesktop.org/show_bug.cgi?id=98898)**
## Description
Created attachment 128263
Add timestamps to dbus-monitor logs
Dbus logs from IVI (In-Vehicle Infotainment) are difficult or impossible to fully analyse because they do not have timestamps.
**Patch 128263**, "Add timestamps to dbus-monitor logs":
[add-timestamps-to-dbus-monitor-logs.patch](/uploads/385e2a020b1bc738f7c900b091c9961c/add-timestamps-to-dbus-monitor-logs.patch)https://gitlab.freedesktop.org/dbus/dbus/-/issues/160No 'org.freedesktop.DBus.Error.PropertyWriteOnly' error2018-10-15T13:45:43ZBugzilla Migration UserNo 'org.freedesktop.DBus.Error.PropertyWriteOnly' error## Submitted by nschoe
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98722)](https://bugs.freedesktop.org/show_bug.cgi?id=98722)**
## Description
DBus properties can have 3 different access mode:
- readonly
- read
-...## Submitted by nschoe
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98722)](https://bugs.freedesktop.org/show_bug.cgi?id=98722)**
## Description
DBus properties can have 3 different access mode:
- readonly
- read
- write
When trying to set a new value to a `readonly` property, we get the DBus error: `org.freedesktop.DBus.Error.PropertyReadOnly`, but there is no such equivalent for trying to read a `write` property.
Admittedly this should not happen too often as I read that the use of write-only properties is discouraged, but since it is explicitly supported, I think we should provide a proper error.https://gitlab.freedesktop.org/dbus/dbus/-/issues/159Please support a relocatable root2018-10-12T21:29:03ZBugzilla Migration UserPlease support a relocatable root## Submitted by Michael Terry
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98260)](https://bugs.freedesktop.org/show_bug.cgi?id=98260)**
## Description
Created attachment 127303
proposed patch
It would be nice if D...## Submitted by Michael Terry
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98260)](https://bugs.freedesktop.org/show_bug.cgi?id=98260)**
## Description
Created attachment 127303
proposed patch
It would be nice if DBus added support for a runtime relocatable root in Unix. i.e. at runtime, be able to be run from /opt/dbus/ or some such, without having that be a compile-time prefix.
I notice the Windows version has some basic support for this. Detecting its installation directory and treating paths as relative to that.
My specific use case is testing a snap [1] of a full desktop environment. This bundled in dbus and session services and all sorts of things. The session DBus was trying to activate services with their compile-time hardcoded paths and not finding them.
And I bet similar use cases exist.
The plumbing already exists to fix those paths up, thanks to the Windows support.
So I threw together a patch for the Unix side of things, to listen to the new variable DBUS_ROOT. If you prefer a different env name, let me know.
[1] http://snapcraft.io/
**Patch 127303**, "proposed patch":
[0001-Support-runtime-relocation-in-Unix-with-the-DBUS_ROO.patch](/uploads/ec7dbdfd1bc750e8726057012fd6bdee/0001-Support-runtime-relocation-in-Unix-with-the-DBUS_ROO.patch)
Version: git master
### See also
* https://launchpad.net/bugs/1633520https://gitlab.freedesktop.org/dbus/dbus/-/issues/158Add an org.fdo.Introspectable2 interface which returns structured introspecti...2023-10-17T13:17:40ZBugzilla Migration UserAdd an org.fdo.Introspectable2 interface which returns structured introspection data## Submitted by Philip Withnall
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98006)](https://bugs.freedesktop.org/show_bug.cgi?id=98006)**
## Description
Receiving introspection data from D-Bus as XML means that any...## Submitted by Philip Withnall
Assigned to **D-Bus Maintainers**
**[Link to original bug (#98006)](https://bugs.freedesktop.org/show_bug.cgi?id=98006)**
## Description
Receiving introspection data from D-Bus as XML means that anybody consuming that data needs to have an XML parser, which is a bit of a pain if that software otherwise doesn’t need to depend on an XML parser.
Simon and I discussed potentially providing introspection data using the D-Bus type system (i.e. as basically a GVariant) as an alternative — org.freedesktop.DBus.Introspectable2.
Services would have to implement this interface before clients can use it. It would be allowed for a service to implement o.f.D.Introspectable, or o.f.D.Introspectable2, or both, or neither. If all the popular D-Bus libraries implemented both o.f.D.Introspectable and o.f.D.Introspectable2 then high coverage of services could be achieved fairly rapidly.
Here’s my suggestion for the interface design. Unless anybody has any objections, I’ll go ahead and implement it.
```
interface org.freedesktop.DBus.Introspectable2
{
org.freedesktop.DBus.Introspectable2.Introspect (out a(sa(sa(sa(sgya{sv})a{sv})a(sa(sga{sv})a{sv})a(sgya{sv})a{sv})a{sv}) introspection_data)
}
```
Because that type string is hideous, here it is in a more block-like format:
```
array of object structs /* calling it ‘object’ rather than ‘node’ seems clearer */
{
string path /* node name from the XML format */
array of interface structs
{
string name
array of method structs
{
string name
array of method argument structs
{
string name
signature type
byte direction /* enum of: in, out */
dict<string, variant> annotations
}
dict<string, variant> annotations
}
array of signal structs
{
string name
array of signal argument structs
{
string name
signature type
dict<string, variant> annotations
/* note: no direction, because it’s always out for signals */
}
dict<string, variant> annotations
}
array of property structs
{
string name
signature type
byte access_flags /* flags of: read, write, read|write */
dict<string, variant> annotations
}
dict<string, variant> annotations
}
dict<string, variant> annotations
}
```
The data format is a fairly direct conversion of the existing introspection XML format, with the differences that:
* it allows annotations anywhere (bug #86162);
* nodes cannot be nested, and must provide their path; they must all be listed in the top-level array, specifying their absolute path instead of nesting;
* argument names are not optional (because it is really annoying to see ‘arg0’, ‘arg1’, etc. in D-Feet);
* argument directions are required for method arguments, and are not specified for signal arguments.
The same semantics for empty nodes as given in the specification applies: if a node is empty (its interfaces array is empty), it is assumed that the service has elected not to return introspection data for that node because doing so is too expensive. The client should introspect that node explicitly to get the introspection data.
I should note that this interface is very much intended to return programmatically-generated introspection data. Implementing Introspect() by hand would be a massive headache. As such, I haven’t made any effort to make it easy to write this stuff manually.
I suggest documentation is encoded using Markdown strings (as is the current fashion) as annotations (key name: org.freedesktop.DBus.Introspectable2.Documentation, value: a{ss} mapping a locale name (see `man setlocale`, e.g. ‘en_GB’) to a documentation string in the given language). This differs from previous approaches (see bug #88997), none of which have been formalised in the specification. org.gtk.GDBus.DocString uses DocBook strings; the ‘doc’ namespace uses its own XML elements; and inline XML comments use old-style gtk-doc syntax (i.e. a combination of DocBook and custom syntax). None of these are particularly portable — but I acknowledge that using Markdown means that anyone who consumes the documentation from *this* interface will need a Markdown parser. If they care about documentation, they probably have one of those already. gtk-doc has switched to Markdown syntax in the last few years, and other documentation formats use Markdown too. The idea of support for localisation of documentation is taken from https://wiki.allseenalliance.org/irb/extended_introspection_xml.
Structured type information (as discussed in bug #93912) should be provided as annotations.
Finally, I was wondering about forwards compatibility — this interface is prone to becoming outdated if D-Bus adds some more concepts like properties (even if they are added in a forwards-compatible manner elsewhere in D-Bus). Depending on how likely that is, we could add a ‘version’ argument to the Introspect() method, which controls whether it returns newer versions of the introspection data format. The introspected data itself would have to be returned as a variant, version 1 of which would have the type given above. Personally, I think this is overkill and we should just move to version 3 of the interface if needed, but I thought I should mention the idea just in case.
Feedback very welcome.
Version: git master
*edited for Markdown legibility —smcv*https://gitlab.freedesktop.org/dbus/dbus/-/issues/157[OS X] : enable standard (non-launchd) dbus-launch and the use of privileged ...2020-09-28T12:27:25ZBugzilla Migration User[OS X] : enable standard (non-launchd) dbus-launch and the use of privileged services via the system bus## Submitted by René J.V. Bertin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97927)](https://bugs.freedesktop.org/show_bug.cgi?id=97927)**
## Description
Created attachment 126778
patch against the master branch, #...## Submitted by René J.V. Bertin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97927)](https://bugs.freedesktop.org/show_bug.cgi?id=97927)**
## Description
Created attachment 126778
patch against the master branch, #1e43857
After discussing this on the ML ("about using privileged (KAuth) helpers: system dbus daemon on OS X?") I think it is about time to open a ticket with a patch that I feel I can propose as a reference implementation.
This patch combines 2 wishes of mine:
1- being able to launch a session daemon when logged in remotely to OS X/macOS, i.e. when launchd cannot be used. In that case the OS is used as a traditional Unix, typically with X11 providing remote display, and there are no technical reasons why DBus wouldn't support this mode of operation ("shouldn't" may be a different thing).
I'm including this because making this possible was in fact in large part a side-effect of the 2nd wish:
2- allow the use of privileged services via the system bus, for instance those based on the KF5 KAuth framework.
With hindsight, point 2 was very easy to implement because the the mechanism to launch the privileged service executable is works as intended on OS X. What failed was the basic libdbus initialisation in the service executable, which didn't provide a session bus address entry in the bus_connection_addresses array.
Given the context the exact value of that entry is without importance. On Linux it would be set to "autolaunch:"; in the attached patch I set it to "launchd:env=DBUS_LAUNCHD_SESSION_BUS_SOCKET" because that appears to be an existing convention. Enabling the code path that takes care of setting this fallback value is what made it relevant to include point 1 above.
There are a few points that are open to discussion:
- is "launchd:env=FOO" indeed an appropriate fallback address? I don't think it will ever be used but may overlook a borderline situation.
- should the org.freedesktop.dbus-system.plist launchd profile provided by my patch be installed by default or should it be optional or an operation to be done manually? Note that installing it doesn't load profile.
- should _dbus_lookup_launchd_socket() indeed check the value of DBUS_LAUNCHD_SESSION_BUS_SOCKET in the environment, and if so should that value have priority over the value obtained from launchctl? The intention I had with the addition was to give a similar mechanism to override the "default" session bus as can be achieved on Linux by overriding DBUS_SESSION_BUS_ADDRESS. NB: changing the DBUS_LAUNCHD_SESSION_BUS_SOCKET value via launchctl has an immediate session-wide effect.
**Patch 126778**, "patch against the master branch, #1e43857":
[combined-patch.diff](/uploads/2a377b384d5b2f4e0feb42c19b21e7b3/combined-patch.diff)
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/156wid can be used without initialisation in dbus-launch.c2018-10-15T13:47:30ZBugzilla Migration Userwid can be used without initialisation in dbus-launch.c## Submitted by René J.V. Bertin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97924)](https://bugs.freedesktop.org/show_bug.cgi?id=97924)**
## Description
Going over the code I after noticing that dbus-launch set DB...## Submitted by René J.V. Bertin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97924)](https://bugs.freedesktop.org/show_bug.cgi?id=97924)**
## Description
Going over the code I after noticing that dbus-launch set DBUS_SESSION_BUS_WINDOWID to an invalid wid, I see that the wid variable can indeed be used without having been initialised.
IMHO, either dbus-launch.c should initialise the wid variable to 0 at declaration, or x11_get_address() should be modified as such:
diff --git a/tools/dbus-launch-x11.c b/tools/dbus-launch-x11.c
index a09444b..d79b4a7 100644
--- a/tools/dbus-launch-x11.c
+++ b/tools/dbus-launch-x11.c
@@ -305,10 +305,10 @@ x11_get_address (char **paddress, pid_t *pid, long *wid)
/* locate the selection owner */
owner = XGetSelectionOwner (xdisplay, selection_atom);
- if (owner == None)
- return TRUE; /* no owner */
if (wid != NULL)
*wid = (long) owner;
+ if (owner == None)
+ return TRUE; /* no owner */
/* get the bus address */
result = XGetWindowProperty (xdisplay, owner, address_atom, 0, 1024, False,
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/155DBus Manpage concerning SELinux wrong2018-10-15T13:47:43ZBugzilla Migration UserDBus Manpage concerning SELinux wrong## Submitted by Ralf Spenneberg
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97528)](https://bugs.freedesktop.org/show_bug.cgi?id=97528)**
## Description
We have played around with dbus and SELinux. The only availab...## Submitted by Ralf Spenneberg
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97528)](https://bugs.freedesktop.org/show_bug.cgi?id=97528)**
## Description
We have played around with dbus and SELinux. The only available documentation appears to be the dbus manpage. Unfortunately the example concerning the associate given in this manpage is not correct:
<associate own="org.freedesktop.Foobar" context="foo_t"/>
This should associate the ownership of the dbus service org.freedesktop.Foobar to the selinux domain foo_t. Actually you have to specify the full security context:
<associate own="org.freedesktop.Foobar" context="system_u:object_r:foo_t:s0"/>https://gitlab.freedesktop.org/dbus/dbus/-/issues/154how to identify which processing is leaking?2018-10-15T13:49:34ZBugzilla Migration Userhow to identify which processing is leaking?## Submitted by Joshua Pritikin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97439)](https://bugs.freedesktop.org/show_bug.cgi?id=97439)**
## Description
I have a bug very similar to https://bugs.kde.org/show_bug.cg...## Submitted by Joshua Pritikin
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97439)](https://bugs.freedesktop.org/show_bug.cgi?id=97439)**
## Description
I have a bug very similar to https://bugs.kde.org/show_bug.cgi?id=261180
However, I don't know how to identify which dbus client is causing the trouble. Can you point me to instructions to diagnose the issue?
Version: 1.10https://gitlab.freedesktop.org/dbus/dbus/-/issues/153Remove platform-specific code from DBusWatch2018-10-15T13:49:58ZBugzilla Migration UserRemove platform-specific code from DBusWatch## Submitted by Thomas Zimmermann
Assigned to **Thomas Zimmermann**
**[Link to original bug (#97358)](https://bugs.freedesktop.org/show_bug.cgi?id=97358)**
## Description
DBusWatch contains platform-specific code, which should be ...## Submitted by Thomas Zimmermann
Assigned to **Thomas Zimmermann**
**[Link to original bug (#97358)](https://bugs.freedesktop.org/show_bug.cgi?id=97358)**
## Description
DBusWatch contains platform-specific code, which should be removed. The file dbus-watch.c already has a TODO item about this.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/152libdbus WaitingForOK state handling does not appear to match spec2018-10-15T13:50:13ZBugzilla Migration Userlibdbus WaitingForOK state handling does not appear to match spec## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97298)](https://bugs.freedesktop.org/show_bug.cgi?id=97298)**
## Description
+++ This bug was initially created as a clone of Bug #97282 ++...## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#97298)](https://bugs.freedesktop.org/show_bug.cgi?id=97298)**
## Description
+++ This bug was initially created as a clone of Bug #97282 +++
gcc 6 warns that
static const DBusAuthStateData client_state_waiting_for_ok
is unused. This suggests that either DBusAuth is doing something in the client side of authentication that doesn't match what dbus-specification says it should do, or the states in DBusAuth don't exactly match the states in dbus-specification.
For now I'm going to mark it as _DBUS_GNUC_UNUSED so the build at least succeeds.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/151AppArmor mode not reloaded until a process reconnects2018-10-15T13:50:59ZBugzilla Migration UserAppArmor mode not reloaded until a process reconnects## Submitted by Philip Withnall
Assigned to **D-Bus Maintainers**
**[Link to original bug (#96720)](https://bugs.freedesktop.org/show_bug.cgi?id=96720)**
## Description
• I have a process (A) running in enforce mode under AppArmor...## Submitted by Philip Withnall
Assigned to **D-Bus Maintainers**
**[Link to original bug (#96720)](https://bugs.freedesktop.org/show_bug.cgi?id=96720)**
## Description
• I have a process (A) running in enforce mode under AppArmor, and connected to dbus-daemon
• Process B is also running in enforce mode, and the profile for process A does not allow incoming method calls from process B (but doesn’t deny them either)
• Process B tries to call a method on process A — this is correctly rejected by dbus-daemon
• I call `sudo aa-complain /path/to/process/A` to switch process A to complain mode, which instantly affects all AppArmor decisions made on the syscall boundary for it
• Process B should now be able to call methods on process A, but they are still denied
• If I restart process A, process B //can// now call methods on it
So it seems like the AppArmor mode for a connection to dbus-daemon is being cached and not updated when it changes in the kernel.
dbus version 1.10.8 on an Ubuntu derivative.
Version: 1.10https://gitlab.freedesktop.org/dbus/dbus/-/issues/150W32: dbus does not support SSPI-based authentication mechanisms2019-05-31T18:24:51ZBugzilla Migration UserW32: dbus does not support SSPI-based authentication mechanisms## Submitted by LRN
Assigned to **D-Bus Maintainers**
**[Link to original bug (#96577)](https://bugs.freedesktop.org/show_bug.cgi?id=96577)**
## Description
As discussed on dbus@lists.freedesktop.org ML, dbus could use
an actual O...## Submitted by LRN
Assigned to **D-Bus Maintainers**
**[Link to original bug (#96577)](https://bugs.freedesktop.org/show_bug.cgi?id=96577)**
## Description
As discussed on dbus@lists.freedesktop.org ML, dbus could use
an actual OS-supported authentication on Windows (EXTERNAL on Windows
is a hack, DBUS_COOKIE_SHA1 has obvious drawbacks).
### Depends on
* [Bug 99512](https://bugs.freedesktop.org/show_bug.cgi?id=99512)https://gitlab.freedesktop.org/dbus/dbus/-/issues/149Memory leak when running test-(d)bus test on Windows2023-01-06T09:14:30ZBugzilla Migration UserMemory leak when running test-(d)bus test on Windows## Submitted by yfei
Assigned to **D-Bus Maintainers**
**[Link to original bug (#95191)](https://bugs.freedesktop.org/show_bug.cgi?id=95191)**
## Description
Created attachment 123326
Log from running "nmake check" on Win64 build ...## Submitted by yfei
Assigned to **D-Bus Maintainers**
**[Link to original bug (#95191)](https://bugs.freedesktop.org/show_bug.cgi?id=95191)**
## Description
Created attachment 123326
Log from running "nmake check" on Win64 build using VS2013.
When running test-dbus spawn, I get memory leak errors. Full unit test output is attached. Test was run in Win10 x64, VS2013 compiler, "nmake check".
**Attachment 123326**, "Log from running "nmake check" on Win64 build using VS2013.":
[LastTest.log](/uploads/3a1add486baccbb67fbe4e2182a24610/LastTest.log)
Version: 1.10
See also #279Ralf HabackerRalf Habackerhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/148There are no options to automatically create a socket directory.2018-10-15T13:53:37ZBugzilla Migration UserThere are no options to automatically create a socket directory.## Submitted by Aleksey Avdeev
Assigned to **D-Bus Maintainers**
**[Link to original bug (#94638)](https://bugs.freedesktop.org/show_bug.cgi?id=94638)**
## Description
Current version of dbus not provide settings for automatically...## Submitted by Aleksey Avdeev
Assigned to **D-Bus Maintainers**
**[Link to original bug (#94638)](https://bugs.freedesktop.org/show_bug.cgi?id=94638)**
## Description
Current version of dbus not provide settings for automatically creating directories for use sockets.
I offer :
1. Add to configure the option, causes the creation of a configuration file for systemd-tmpfiles.
2. The generated unit files indicate that systemd-tmpfiles-setup.service should start before dbus.https://gitlab.freedesktop.org/dbus/dbus/-/issues/147dbus-1.10 (1.10.6 and 1.0.8 tries) breaks gnome 3.18 logout leaving running p...2018-10-15T13:54:29ZBugzilla Migration Userdbus-1.10 (1.10.6 and 1.0.8 tries) breaks gnome 3.18 logout leaving running processes## Submitted by Pacho Ramos
Assigned to **D-Bus Maintainers**
**[Link to original bug (#94508)](https://bugs.freedesktop.org/show_bug.cgi?id=94508)**
## Description
For some days I am suffering an strange behavior: when I logout, ...## Submitted by Pacho Ramos
Assigned to **D-Bus Maintainers**
**[Link to original bug (#94508)](https://bugs.freedesktop.org/show_bug.cgi?id=94508)**
## Description
For some days I am suffering an strange behavior: when I logout, lots of processes from the gnome session are kept running. This causes problems when other users try to login in their accounts.
Googling a bit, I saw the same problem on Arch (I am using Gentoo):
https://bbs.archlinux.org/viewtopic.php?id=204307
And I have seen that this is caused by dbus-1.10.x upgrade, if I switch back 1.8.x releases all go back to normal and processes die when logging out
Thanks a lot for your help :)
Version: 1.10https://gitlab.freedesktop.org/dbus/dbus/-/issues/146Included configuration file "org.freedesktop.dbus-session.plist" contains dep...2020-09-28T11:45:51ZBugzilla Migration UserIncluded configuration file "org.freedesktop.dbus-session.plist" contains deprecated fields, requires user intervention on old OSX## Submitted by Zac Bentley
Assigned to **D-Bus Maintainers**
**[Link to original bug (#94494)](https://bugs.freedesktop.org/show_bug.cgi?id=94494)**
## Description
There is a plist file included with the dbus distro to make it pl...## Submitted by Zac Bentley
Assigned to **D-Bus Maintainers**
**[Link to original bug (#94494)](https://bugs.freedesktop.org/show_bug.cgi?id=94494)**
## Description
There is a plist file included with the dbus distro to make it place nicely with OSX's launchd. That file is visible at https://cgit.freedesktop.org/dbus/dbus/tree/bus/org.freedesktop.dbus-session.plist.in
It has two issues on recent (post 10.4/10.5) versions of the OSX operating system:
- It uses the deprecated "ServiceIPC" key. This either does nothing (deceptive) or generates lots of warnings in the OSX syslog equivalent complaining about the use of a deprecated field. See the following link for admittedly sketchy info on the deprecation, though the warnings definitely do occur on versions after 10.4: http://mac-os-forge.2317878.n4.nabble.com/About-the-ServiceIPC-key-td189335.html
- It has a manually-commented section disabling the "OnDemand" key, with user instructions to uncomment that section on OSX 10.4.
These require user intervention to suppress errors on new OSX versions or to get things working on old versions.
Two fixes should be made:
- The plist file should be templated by the build system, and the "ServiceIPC" key should be removed on OSX versions greater than 10.4.
- The "OnDemand" section should only be present on OSX versions <= 10.4; it should be ommitted in subsequent versions. If users want to hand-configure OnDemand enabling or disabling for other reasons, they are free to do so.
Version: git master