d73874c7ab
dbus 1.14.4 (2022-10-05)
========================
This is a security update for the dbus 1.14.x stable branch, fixing
denial-of-service issues (CVE-2022-42010, -42011, -42012) and applying
security hardening (dbus#416).
Behaviour changes:
• On Linux, dbus-daemon and other uses of DBusServer now create a
path-based Unix socket, unix:path=..., when asked to listen on a
unix:tmpdir=... address. This makes unix:tmpdir=... equivalent to
unix:dir=... on all platforms.
Previous versions would have created an abstract socket, unix:abstract=...,
in this situation.
This change primarily affects the well-known session bus when run via
dbus-launch(1) or dbus-run-session(1). The user bus, enabled by configuring
dbus with --enable-user-session and running it on a systemd system,
already used path-based Unix sockets and is unaffected by this change.
This behaviour change prevents a sandbox escape via the session bus socket
in sandboxing frameworks that can share the network namespace with the host
system, such as Flatpak.
This change might cause a regression in situations where the abstract socket
is intentionally shared between the host system and a chroot or container,
such as some use-cases of schroot(1). That regression can be resolved by
using a bind-mount to share either the D-Bus socket, or the whole /tmp
directory, with the chroot or container.
(dbus#416, Simon McVittie)
Denial of service fixes:
Evgeny Vereshchagin discovered several ways in which an authenticated
local attacker could cause a crash (denial of service) in
dbus-daemon --system or a custom DBusServer. In uncommon configurations
these could potentially be carried out by an authenticated remote attacker.
• An invalid array of fixed-length elements where the length of the array
is not a multiple of the length of the element would cause an assertion
failure in debug builds or an out-of-bounds read in production builds.
This was a regression in version 1.3.0.
(dbus#413, CVE-2022-42011; Simon McVittie)
• A syntactically invalid type signature with incorrectly nested parentheses
and curly brackets would cause an assertion failure in debug builds.
Similar messages could potentially result in a crash or incorrect message
processing in a production build, although we are not aware of a practical
example. (dbus#418, CVE-2022-42010; Simon McVittie)
• A message in non-native endianness with out-of-band Unix file descriptors
would cause a use-after-free and possible memory corruption in production
builds, or an assertion failure in debug builds. This was a regression in
version 1.3.0. (dbus#417, CVE-2022-42012; Simon McVittie)
dbus 1.14.2 (2022-09-26)
========================
Fixes:
• Fix build failure on FreeBSD (dbus!277, Alex Richardson)
• Fix build failure on macOS with launchd enabled
(dbus!287, Dawid Wróbel)
• Preserve errno on failure to open /proc/self/oom_score_adj
(dbus!285, Gentoo#834725; Mike Gilbert)
• On Linux, don't log warnings if oom_score_adj is read-only but does not
need to be changed (dbus!291, Simon McVittie)
• Slightly improve error-handling for inotify
(dbus!235, Simon McVittie)
• Don't crash if dbus-daemon is asked to watch more than 128 directories
for changes (dbus!302, Jan Tojnar)
• Autotools build system fixes:
· Don't treat --with-x or --with-x=yes as a request to disable X11,
fixing a regression in 1.13.20. Instead, require X11 libraries and
fail if they cannot be detected. (dbus!263, Lars Wendler)
· When a CMake project uses an Autotools-built libdbus in a
non-standard prefix, find dbus-arch-deps.h successfully
(dbus#314, Simon McVittie)
· Don't include generated XML catalog in source releases
(dbus!317, Jan Tojnar)
· Improve robustness of detecting gcc __sync atomic builtins
(dbus!320, Alex Richardson)
• CMake build system fixes:
· Detect endianness correctly, fixing interoperability with other D-Bus
implementations on big-endian systems (dbus#375, Ralf Habacker)
· When building for Unix, install session and system bus setup
in the intended locations
(dbus!267, dbus!297; Ralf Habacker, Alex Richardson)
· Detect setresuid() and getresuid() (dbus!319, Alex Richardson)
· Detect backtrace() on FreeBSD (dbus!281, Alex Richardson)
· Don't include headers from parent directory (dbus!282, Alex Richardson)
· Distinguish between host and target TMPDIR when cross-compiling
(dbus!279, Alex Richardson)
· Fix detection of atomic operations (dbus!306, Alex Richardson)
Tests and CI enhancements:
• On Unix, skip tests that switch uid if run in a container that is
unable to do so, instead of failing (dbus#407, Simon McVittie)
• Use the latest MSYS2 packages for CI
(Ralf Habacker, Simon McVittie)
License-Update: D-Bus changed to dbus.
(From OE-Core rev: fbf8ea03aeb04e1efdc9693a66d618275bddc172)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 8c2ab4c014807e2d8ad0fded4188578aa05e8c55)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Poky
Poky is an integration of various components to form a pre-packaged build system and development environment which is used as a development and validation tool by the Yocto Project. It features support for building customised embedded style device images and custom containers. There are reference demo images ranging from X11/GTK+ to Weston, commandline and more. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK suitable for IDE integration.
Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of BSP layers which extend the systems capabilities in a modular way. Many layers are available and can be found through the layer index.
As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation, the 'meta-yocto' layer which has configuration and hardware support components. These components are all part of the Yocto Project and OpenEmbedded ecosystems.
The Yocto Project has extensive documentation about the system including a reference manual which can be found at https://docs.yoctoproject.org/
OpenEmbedded is the build architecture used by Poky and the Yocto project. For information about OpenEmbedded, see the OpenEmbedded website.
Contribution Guidelines
The project works using a mailing list patch submission process. Patches should be sent to the mailing list for the repository the components originate from (see below). Throughout the Yocto Project, the README files in the component in question should detail where to send patches, who the maintainers are and where bugs should be reported.
A guide to submitting patches to OpenEmbedded is available at:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
There is good documentation on how to write/format patches at:
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Where to Send Patches
As Poky is an integration repository (built using a tool called combo-layer), patches against the various components should be sent to their respective upstreams:
OpenEmbedded-Core (files in meta/, meta-selftest/, meta-skeleton/, scripts/):
- Git repository: https://git.openembedded.org/openembedded-core/
- Mailing list: openembedded-core@lists.openembedded.org
BitBake (files in bitbake/):
- Git repository: https://git.openembedded.org/bitbake/
- Mailing list: bitbake-devel@lists.openembedded.org
Documentation (files in documentation/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/
- Mailing list: docs@lists.yoctoproject.org
meta-yocto (files in meta-poky/, meta-yocto-bsp/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto
- Mailing list: poky@lists.yoctoproject.org
If in doubt, check the openembedded-core git repository for the content you intend to modify as most files are from there unless clearly one of the above categories. Before sending, be sure the patches apply cleanly to the current git repository branch in question.