Comment 8 for bug 1802533

I reviewed pipewire 0.2.5-1 as checked into eoan. This shouldn't be considered a full audit but rather a quick gauge of maintainability.

pipewire is a multimedia sharing and processing engine. It is comprised of a server and userspace API to handle multimedia pipelines. The pipewire package contains a library, utilities, a daemon and
several plugins.

pipewire seems to be relatively new and indications are that while usable, it is still being developed (https://github.com/PipeWire/pipewire/wiki/FAQ).

It is meant to overhaul audit/video processing by doing what pulseaudio and Jack do and leveraging Wayland remote screen capabilities.

- No CVEs. Also examined git repository in github, https://github.com/PipeWire/pipewire. Seems to be a lot of active development and bugfixing.
- Build-Depends: debhelper (>= 11), libasound2-dev, libavcodec-dev, libavfilter-dev, libavformat-dev, libdbus-1-dev, libglib2.0-dev, libgstreamer1.0-dev, libgstreamer-plugins-base1.0-dev, libsbc-dev,
libsdl2-dev, libudev-dev, libva-dev, libv4l-dev, libx11-dev, meson (>= 0.47), pkg-config (>= 0.22), systemd, xmltoman, doxygen, graphviz
**Note: Uses meson build system
- There are no pre/post inst/rm scripts.
- No init scripts
- There are systemd unit files
  - There is pipewire.socket, a systemd socket unit for automatic socket activation. Appears to be a
    AF_Unix socket
  - There is pipewire.service, a system unit file for the daemon. It requires the pipewire.socket to
    be active first.
- dbus services are used
  - the rtkit (realtimekit) module uses dbus to talk to RealtimeKit to be allowed permission to take
    on realtime property.
  - the flatpak module uses dbus in similar manner to acquire permission to record screen or audio.
  - the Simple plugin API provides dbus services via D-Bus low-level public API to plugins.
- No setuid binaries
- Several binaries installed in /usr/bin/ and /usr/lib/x86_64-linux-gnu/ dirs.
- No sudo fragments.
- No udev rules. However, the ALSA (advanced linux sound architecture) and V4l2 (video) plugins
  do make udev calls to acquire device info.
- No autopkgtests. There are a few tests in spa/test dir but they do not seem to have run.
- No cron jobs.
- Build logs indicated a successful build. However there was a compile error and many compile warnings pertaining to -Wdepracated-declarations and -Wunused-result. There also appeared to be many failures while generating docs.
- No processes spawned.
- Quite a bit of memory mgmt. Inspecting a random sampling of memory mgmt routines, the memcpy() seem ok, the return value not checked for any of the asprintf() and a number of calloc()|realloc() did not check the return value for failure.
- No File IO issues readily found. Noticed v4l2 plugin open() the playback(video capture) device. The default is /dev/video0. The alsa plugin opens an audio device using snd_pcm_open. The default device is hw:0.
- Logging: both pipewire and spa (simple plugin api) define their own logging facilities. Use of vsnprintf seems ok. Noted that except for pw_log_trace, logging appears to go to stderr... pw_log_trace writes to a lockfree ringbuffer which seems to be written out from main thread.
- There are environment variables. They appear to be ok.
- No File IO issues. The v4l2 plugin uses ioctl cnd xioctl calls on VIDIOC_*, the videocapture device. Look ok.
- pipewire uses a random number to generate a random cookie that identifies the instance of pipewire
- No temp file issues.
- Networking: pipewire seem to use "nodes" which are physical playback and recording points for audio. Nodes can be separate processes that use sockets and filedescriptors to communicate and pass around multimedia data. pipewire opens local sockets and pass around file descriptors to do this.
- Does not use WebKit.
- Does not use PolicyKit.
- cppcheck results:
  [spa/tests/test-props4.c:147]: (error) va_list 'args' was opened but not closed by va_end().
  [spa/tests/test-props4.c:427]: (error) va_list 'args' was opened but not closed by va_end().
- Coverity not run.

Misc Notes:
Entry from https://github.com/PipeWire/pipewire/wiki/FAQ,
"Is PipeWire ready yet?

No, it is under heavy development

It is currently reasonably safe to use the remote API to connect to a PipeWire daemon and the stream API (stream.h) to send and retrieve data. I do not expect this API to change in incompatible ways.

The protocol is not fixed yet; it is not safe to assume I will make backward compatible changes in the future. This means that it is not safe to assume that older versions of the library will be able to communicate with newer versions of the daemon (or vice versa). This is usually not a problem because both client and server share the same version of the library. It can be a problem when dealing with sandboxes that have their own (old) copy of PipeWire."

The security team will NAK this for now. The above FAQ entry indicates
pipewire is still under heavy development and there are no promises of backward
compatibility for some things during this time. Some code cleanup needed in regards to memory allocations and asprintf needing returns checked. It may be better to postpone this for a future interim release.