While writing the wording to deprecate XML policy installed by packages
into ${sysconfdir}, I realised we didn't give a typical example of
what packages *should* do.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Now that dbus 1.10 has become widely available, we should start to
treat ${sysconfdir} as reserved for the sysadmin, and encourage
third-party software packages to install their integration files into
${datadir}.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If lists are in a completely arbitrary order, sorting them consistently
means that there is only one correct place to insert a new entry, avoiding
the merge conflicts that would occur if we always append new entries.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Patterns in the top-level .gitignore match in all subdirectories, so
there's no need to repeat ourselves quite so much for generic
C, Autotools and gcov patterns.
Signed-off-by: Simon McVittie <smcv@collabora.com>
test/dbus-daemon: Mark max-connections-per-user as unimplemented on Windows
See merge request dbus/dbus!54
Reviewed-by: pwithnall
Reviewed-by: rhabacker
This saves around 32% of the size of the archive.
[smcv: Rebased onto current master]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107630
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>
This is the default, and blocks TCP-based attacks by making the
attacker fail to authenticate (while also preventing inadvisable
TCP-based configurations from working).
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>
I'm far from convinced that this option should even *exist*, but it
should definitely be documented as a very bad thing.
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>
The old version-1 format is deprecated and now produces warnings.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106186
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add the .devhelp2 file to .gitignore as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
The tutorial is not necessarily a great entry point for the libdbus
documentation: it's infrequently updated, and we should probably have
the "If you use this low-level API directly, you're signing up for some
pain" message from the API reference show up in devhelp more immediately.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106186
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add longer commit message with rationale]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Newer versions of yelp-build use this instead of a jQuery syntax
highlighter.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106171
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Also add it to .gitignore as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is an interpretation of the existing text. There are two plausible
ways a relaying server could interpret "must ignore [new] fields":
it could pass them through as-is, or it could delete them before
relaying. Until now, the reference implementation has done the former.
However, this behaviour is difficult to defend. If a server relays
messages without filtering out header fields that it doesn't
understand, then a client can't know whether the header field was
supplied by the server, or whether it was supplied by a (possibly
malicious) fellow client.
We can't introduce useful round-trip-reducing header fields like
SENDER_UNIX_USER_ID or SENDER_LINUX_SECURITY_LABEL until the
message bus filters them out, *and* provides a way for clients to
know for sure that it has done so. This is a step towards that
feature.
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>
The Telepathy "Tubes" APIs are an example of a server that is not a
message bus, but makes use of the sender and destination fields to
provide broadly unique-connection-name-like semantics.
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>
