| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The interoperable address is unix:path=/var/run/dbus/system_bus_socket.
However, in most (perhaps all) current Linux distributions, /var/run
is guaranteed to be a symbolic link to /run, and using the path in /run
has some advantages (particularly if automounters are used).
Implementations that intend to be interoperable are not required to
listen on exactly /var/run/dbus/system_bus_socket, as long as clients
that connect to that socket will work correctly. Similarly, clients
are not required to connect to exactly /var/run/dbus/system_bus_socket,
as long as the overall system (consisting of the client and the OSs
that it supports) ensures that it ends up connecting to the same
well-known system bus that is available at
/var/run/dbus/system_bus_socket.
Because of the Unix conventions for how software installs into a prefix,
building a D-Bus implementation with its default build-time
configuration options will not necessarily result in an interoperable
system bus. The system bus is normally shipped by OS distributors,
who should ensure that they have configured it in a way that is
interoperable.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/180
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
|
|
|
|
|
|
|
|
| |
The comment refers to the nul-padding of sockaddr_un member sun_path and
using an addrlen of sizeof(sockaddr_un). There is not much need to
document an old now "broken" behaviour.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
D-Bus names are in an ASCII subset, so IDNs have to be in their ACE
encoding (Punycode). ACE-encoded labels contain hyphen/minus characters,
and like any other label containing a hyphen/minus, we recommend
replacing those with underscores, to improve interoperability with
contexts that allow underscores but not hyphen/minus, such as
D-Bus object paths and Flatpak app-IDs.
Prompted by <https://github.com/flatpak/flatpak/issues/4974>.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
| |
This reverts commit 428f60e8b2f5e3f1871c3173700bbe2d8139e242.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
| |
Nothing changed in v0.39 yet, and it would be confusing to have the
version uploaded alongside dbus 1.14.0 say "not yet finalized".
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
| |
feature
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
|
|
|
|
|
|
|
|
|
|
|
| |
Commit ee71e1ff6033a added * to the list of optionally escaped bytes
set, but did not update the documentation. I guess this happened because
the change is not backward compatible.
It seems that the period of 14+ years should be enough to not cause any
backward compatibility issues, so let's document this.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
| |
Since we're heading for a 1.14.x branch (dbus#350), also draft the
summary of what has changed since 1.12.x.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
| |
fixes #347
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This had two issues that could damage interoperability.
First, the spec wording suggested that any cookie that had not been
deleted was suitable for use in authentication. However, this introduces
a race condition, which is called out in comments in both the reference
implementation and GDBus: the newest cookie might be less old than the
arbitrary lifetime when authentication *begins*, but older than the
lifetime at the time authentication *ends*. As a result, we need a grace
period during which an old cookie will still be accepted, but a newer
cookie exists and will be used for new authentication operations.
Second, the spec wording implied that the arbitrary timeouts were
completely up to the implementor. However, GLib bug
https://gitlab.gnome.org/GNOME/glib/-/issues/2164 indicates that they
need to be reasonably compatible: in particular, GDBus servers
historically didn't allocate new cookies until 10 minutes had passed,
but libdbus clients would decline to use a cookie older than 5 minutes,
causing authentication to fail if the gdbus-server test-case (in which
GDBus and libdbus clients connect to a GDBus server) happened to take
longer than 5 minutes to run.
While I'm here, also be consistent about calling the secrets "cookies"
(consistent with the name of the mechanism) rather than "keys" (which
is what they are called in libdbus' dbus-keyring.c).
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
| |
The length of "bar" is encoded as 3. The annotation is incorrect.
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
| |
This reverts commit edece0274b37472d7da6db37e8afd9100d18564b.
No spec changes have happened since 0.35.
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Matthijs van Duin <matthijsvanduin@gmail.com>
|
|
|
|
| |
requirements.
|
|
|
|
| |
consist of only 1 element.
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
|
| |
As spotted by Peter Bigot.
Closes #221
Signed-off-by: Philip Withnall <withnall@endlessm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
nonce-tcp isn't really any more secure than tcp, unless you are
using ANONYMOUS authentication, which should not be considered
secure in any case. Avoid the word "secured" so that people don't
get the wrong idea.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This might (?) have made sense behind a firewall in 2003; but now it's
2018, the typical threat model that we are defending against has
changed from "vandals want to feel proud of their l33t skills"
to "organised crime wants your money", and a "trusted" local LAN
probably contains an obsolete phone, tablet, games console or
Internet-of-Things-enabled toaster with remote root exploits.
This make network topologies that used to be acceptable look
increasingly irresponsible.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
|
|
|
| |
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
|
|
|
|
|
|
| |
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
|
|
|
| |
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
|
|
|
|
| |
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add a TODO comment as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With some fairly reasonable threat models (active or passive local
attacker able to eavesdrop on the network link, confidential
information being transferred via D-Bus), secure authentication is
insufficient to make this transport secure: it does not protect
confidentiality or integrity either.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like the normal TCP transport, it has no confidentiality or integrity
protection. The only difference is that it adds an extra layer of
authentication.
However, this extra authentication is easily defeated if an attacker
could be eavesdropping on the link between client and server (unlike
DBUS_COOKIE_SHA1, which for all its flaws does at least protect the
confidentiality of the magic cookie).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
|
|
|
| |
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
| |
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
| |
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
|