[MIR] pipewire

Just comment from a desktop team perspective, that MIR is low priority for us at the moment.

Rational:
The component is new and only adds unencrypted & withoutpassword VNC support to the wayland session which is better than nothing but not enough. Having the feature enabled for our users that opt in for wayland and need VNC would be nice though, so if MIR/security have enough review capacity to get that done please do still

Seb, I believe gnome-remote-desktop offers the same password option that vino does through the same UI in gnome-control-center's Sharing panel.

vino only supports VNC. (To be fair, you could use some other remote desktop service with X but VNC is the only thing we've been directly supporting in main.)

vino does offer encryption but it doesn't work for several major clients. The troublesome part is that vino enables that encryption by default so users have to use dconf-editor or the command line to disable encryption. See LP: #1281250

I expect vino to be removed from "GNOME Core" for 3.32.

Status changed to 'Confirmed' because the bug affects multiple users.

@Jeremy, the MIR here is the pipewire one, not about gnome-remote-desktop vs vino, you maybe commented on the wrong ticket?
(If that was a reply to my comment, the problem with wayland/why we don't consider if for default is not the service enabling VNC, it's other things having your session closing when the shell it a bug, the lack of xrdp option, etc. And anyway, that bug is not the place to argue about wayland not being the default, that's just the fact today and leads to the comment about priority I was making)

I agree remote VNC is not the only blocker for enabling Wayland by default for 20.04 LTS.

I certainly can't see this as a small and easy package to maintain in general. Fortunately, right now it is in sync with Debian, but it's a pretty big codebase. Any issues that might come up, especially security issues, might be effort-intensive, though at a quick glance I didn't notice anything sensitive popping up -- that said, I only did a quick review of the code -- there's some 260 files of source code.

There doesn't appear to be open CVEs, the packaging quality is as one would expect.

There appears to be test sources at least for libspa, but those do not seem to get run by the upstream build process when running 'make check'.

Do you need all the binaries in main? You do mention "not libspa-ffmpeg", but what of the other binaries? If this is just for pipewire binary itself, then it would only require libpipewire-0.2-1 and pipewire.

Assigning to Security Team for a code review.

Please also make sure to set a bug subscriber...

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.
- Ther...

Is this going to get done for Focal? It would be a shame to ship an LTS release without remote desktop support for Wayland. Aren't we at the point now where Wayland is supposed to people's first choice?

+1
It isn't possible to record a screencast with OBS on Wayland

```
error: [OBS XDG] Error creating screencast session: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.portal.ScreenCast” on object at path /org/freedesktop/portal/desktop

```

is there any chance of getting this in Groovy?
it would be nice to start migrating to Wayland-by-default in non-LTS versions, and being unable to screenshare is a blocker for a lot of users

Thanks for the ping Vlad, The old FAQ declaring it not ready yet these days is (quote):
"Is PipeWire ready yet?
It is getting ready for broader testing.
The API in master is now declared stable and not expected to change anymore for the
0.3 release.
The protocol can support older 0.2 version clients transparently. This means that flatpaks
with older PipeWire libraries can connect to a newer daemon."
=> https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#is-pipewire-ready-yet

We will need to ping the Desktop Team if this still would be their path of choice and if they want it to re-enter security evaluation.

Assigning to seb128 who did the last Desktop-direction statements on this in comment #1.

@seb128 - would you mind discussing this with the Desktop Team?
 - if you think this is important these days and you want it to re-enter security assign it
   to ubuntu-security please
 - if changes in the infrastructure happened and this is no more needed/wanted could
   you explain here why and then set it to a "Won't Fix" which would be more clear in
   regard to peoples expectations.

@cpaelzer, thanks for checking with us. Pipewire is where GNOME is heading and is already required for e.g screen sharing to work on Wayland (which isn't our default session at the moment but we still want that working in Ubuntu). I don't think we are ready to switch the desktop this cycle but might aim for next cycle so getting reviews going again now makes sense. I'm reassigning to ubuntu-security as suggested

I have Pipewire 0.3 working on Focal, with at least a few of its reverse-depends working correctly (gnome-remote-desktop, mutter, xdg-desktop-portal)

I'll post a PPA shortly.

Hi, security team is wanting to do a MIR audit on pipewire for groovy. Unfortunately, the current pipewire source downloaded from groovy does not appear to have been updated nor does it build.

Reassigning so that necessary work is done to get pipewire updated, building and working in groovy.

pipewire 0.3 is in NEW in Debian. Once it's cleared out there, we can request an FFe to hopefully get into groovy, and then assign back to the security team for review.

I think it's worth waiting since 0.3 has big changes and this is the version that GNOME depends on.

https://tracker.debian.org/news/1175550/pipewire-0310-4-migrated-to-testing/

Pipewire 0.3.12 landed in Debian testing.

> Reassigning so that necessary work is done to get pipewire updated, building and working

The new version 0.3 serie in Ubuntu, is building and working, reassigning back to ubuntu-security for review (there is a minor version update in Debian but which came a bit late to be synced, it shouldn't make a difference for the review though)

@Liz Fong-Jones

What did you do to get xdg-desktop-portal working in Ubuntu?
I installed pipewire (0.3.10-4 avalible in groovy) and tried to pull xdg-desktop-portal, mutter and mutter-common form Debian but that causes mutter to immediately crash. After restoring mutter and mutter-common I have a usable system again but screen sharing still does not work.

https://launchpad.net/~lizthegrey/+archive/ubuntu/freedesktop -- I backported, rather than directly installing the Debian packages. You need to do a formal backport from source to force linking against Ubuntu's ABI.

Thank you Liz. There are no installable packages on your PPA though.

That is correct, if you're on amd64. I built only for ARM because that's what I need for my device running Wayland (sorry!) but you should be able to clone my PPA and rebuild from source on amd64 if you like.

Thank you Liz! I'll see if I have the energy to do that, but with my company pushing bad remote meeting solutions I might have to :/ Now I at least know where things stand and what to do.

This second review will only document the areas that some difference was found from the first review.

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

- Build-Depends:
debhelper-compat (= 13), libasound2-dev, libbluetooth-dev, libdbus-1-dev, libglib2.0-dev (>= 2.32.0), libgstreamer-plugins-base1.0-dev, libgstreamer1.0-dev, libjack-jackd2-dev (>= 1.9.10), libpulse-dev (>= 11.1), libsbc-dev, libsdl2-dev, libsndfile1-dev (>= 1.0.20), libsystemd-dev,
libudev-dev, libv4l-dev, meson (>= 0.50.0), pkg-config (>= 0.22), systemd, xmltoman, doxygen, graphviz

- pre/post inst/rm scripts:
dh_installsystemduser automatically adds postinst scripts to enable the pipewire.service and pipewire.socket units.
dh_installsystemduser automatically adds a postrm that removes or purges the pipewire.socket and pipewire.service.

- udev rules : 90-pipewire-alsa.rules

- autopkgtests - 3 bash scripts to test interaction with gnome,gstreamer and libpipewire. There are also tests integrated into the source code. They are run during the build cycle. There are also examples and tests packaged in pipewire.test pkg.

- Build logs: Built successfully. However, because the code contains unusual characters in comments, there were many "bogus" warnings during the build. i.e.,
/** \class pw_filter
 *
 * \brief PipeWire filter object class
 *
 * The filter object provides a convenient way to implement
 * processing filters.
 *
 * See also \ref page_filters and \ref page_core_api
 */

- LINTIAN ran successfully with some errors and warnings:
E: pipewire changes: bad-distribution-in-changes-file unstable
E: pipewire-audio-client-libraries: custom-library-search-path usr/lib/x86_64-linux-gnu/pipewire-0.3/pulse/libpulse-mainloop-glib.so.0.315.0 /usr/${LIB}/pipewire-0.3/pulse
E: pipewire-audio-client-libraries: custom-library-search-path usr/lib/x86_64-linux-gnu/pipewire-0.3/pulse/libpulse-simple.so.0.315.0 /usr/${LIB}/pipewire-0.3/pulse
E: pipewire-audio-client-libraries: library-not-linked-against-libc usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjacknet.so.0.315.0
E: pipewire-audio-client-libraries: library-not-linked-against-libc usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjackserver.so.0.315.0
W: pipewire-bin: no-manual-page usr/bin/pipewire-media-session
W: pipewire-bin: no-manual-page usr/bin/pw-reserve
W: pipewire-bin: no-manual-page usr/bin/spa-acp-tool
W: pipewire-bin: no-manual-page usr/bin/spa-inspect
W: pipewire-bin: no-manual-page usr/bin/spa-monitor
W: pipewire-bin: no-manual-page usr/bin/spa-resample
N: 7 tags overridden (7 errors)

- spawns a daemon, code looks ok.

- Memory management:
Quite a bit of malloc|calloc|realloc used without checking return value before use. Especially in spa/plugins.

- A lot of environment variables. Looking at a random sampling, code-wise looks ok, but use of
them in some places may be questionable. i.e.
1. - pw-pulse.in and pw-jack.in shell scripts use and modify LD_LIBRARY_PATH so applications load pipewire's pulseaudio or jack instead of Jack's and PulseAudio's.
2. The pipewire daemon uses env vars to set alternative name and config ile fo...

Hello, what is the status of this MIR? Getting screen sharing to work in Wayland would be a huge improvement in times like these and I'm weary of the "Unassigned, importance low" status that this currently have.

Hi Rasmus,
this looks soemwhat ready to me - it is on the Desktop team to now integrate and thereby trigger the component mismatch that will pull it into main.
I've last week pinged seb128 and didrocks about it - AFAIK they will take a look.

=> https://irclogs.ubuntu.com/2020/11/19/%23ubuntu-desktop.html#t09:23

Thank you Christian, that sounds great!

GNOME Shell will start depending on it in the next release and this is what is going to pull it in main.

@didrocks Any ETA for the 21.04 channel? I'd like to test this asap.

As Ubuntu 21.04 won't have Gnome 40, can this be enabled for the current version (in 21.04 ofc.)?

It's explicitly disabled for Ubuntu here https://salsa.debian.org/gnome-team/mutter/-/blob/debian/master/debian/rules#L41-48

On Mon, Feb 01, 2021 at 10:15:45AM -0000, Rasmus Eneman wrote:
> As Ubuntu 21.04 won't have Gnome 40, can this be enabled for the current
> version (in 21.04 ofc.)?
>
> It's explicitly disabled for Ubuntu here https://salsa.debian.org/gnome-
> team/mutter/-/blob/debian/master/debian/rules#L41-48

Yes, it will be done for 21.04 :-)

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

These were the ones component-mismatches-proposed said were required. If some of them aren't, they'll show for demotion and can be put back to universe then. Thanks!

laney@dev> ./change-override -s hirsute -S -c main pipewire
Override component to main
pipewire 0.3.19-3 in hirsute: universe/misc -> main
gstreamer1.0-pipewire 0.3.19-3 in hirsute amd64: universe/libs/optional/100% -> main
gstreamer1.0-pipewire 0.3.19-3 in hirsute arm64: universe/libs/optional/100% -> main
gstreamer1.0-pipewire 0.3.19-3 in hirsute armhf: universe/libs/optional/100% -> main
gstreamer1.0-pipewire 0.3.19-3 in hirsute ppc64el: universe/libs/optional/100% -> main
gstreamer1.0-pipewire 0.3.19-3 in hirsute riscv64: universe/libs/optional/100% -> main
gstreamer1.0-pipewire 0.3.19-3 in hirsute s390x: universe/libs/optional/100% -> main
libpipewire-0.3-0 0.3.19-3 in hirsute amd64: universe/libs/optional/100% -> main
libpipewire-0.3-0 0.3.19-3 in hirsute arm64: universe/libs/optional/100% -> main
libpipewire-0.3-0 0.3.19-3 in hirsute armhf: universe/libs/optional/100% -> main
libpipewire-0.3-0 0.3.19-3 in hirsute ppc64el: universe/libs/optional/100% -> main
libpipewire-0.3-0 0.3.19-3 in hirsute riscv64: universe/libs/optional/100% -> main
libpipewire-0.3-0 0.3.19-3 in hirsute s390x: universe/libs/optional/100% -> main
libpipewire-0.3-dev 0.3.19-3 in hirsute amd64: universe/libdevel/optional/100% -> main
libpipewire-0.3-dev 0.3.19-3 in hirsute arm64: universe/libdevel/optional/100% -> main
libpipewire-0.3-dev 0.3.19-3 in hirsute armhf: universe/libdevel/optional/100% -> main
libpipewire-0.3-dev 0.3.19-3 in hirsute ppc64el: universe/libdevel/optional/100% -> main
libpipewire-0.3-dev 0.3.19-3 in hirsute riscv64: universe/libdevel/optional/100% -> main
libpipewire-0.3-dev 0.3.19-3 in hirsute s390x: universe/libdevel/optional/100% -> main
libpipewire-0.3-modules 0.3.19-3 in hirsute amd64: universe/libs/optional/100% -> main
libpipewire-0.3-modules 0.3.19-3 in hirsute arm64: universe/libs/optional/100% -> main
libpipewire-0.3-modules 0.3.19-3 in hirsute armhf: universe/libs/optional/100% -> main
libpipewire-0.3-modules 0.3.19-3 in hirsute ppc64el: universe/libs/optional/100% -> main
libpipewire-0.3-modules 0.3.19-3 in hirsute riscv64: universe/libs/optional/100% -> main
libpipewire-0.3-modules 0.3.19-3 in hirsute s390x: universe/libs/optional/100% -> main
libspa-0.2-bluetooth 0.3.19-3 in hirsute amd64: universe/libs/optional/100% -> main
libspa-0.2-bluetooth 0.3.19-3 in hirsute arm64: universe/libs/optional/100% -> main
libspa-0.2-bluetooth 0.3.19-3 in hirsute armhf: universe/libs/optional/100% -> main
libspa-0.2-bluetooth 0.3.19-3 in hirsute ppc64el: universe/libs/optional/100% -> main
libspa-0.2-bluetooth 0.3.19-3 in hirsute riscv64: universe/libs/optional/100% -> main
libspa-0.2-bluetooth 0.3.19-3 in hirsute s390x: universe/libs/optional/100% -> main
libspa-0.2-dev 0.3.19-3 in hirsute amd64: universe/libdevel/optional/100% -> main
libspa-0.2-dev 0.3.19-3 in hirsute arm64: universe/libdevel/optional/100% -> main
libspa-0.2-dev 0.3.19-3 in hirsute armhf: universe/libdevel/optional/100% -> main
libspa-0.2-dev 0.3.19-3 in hirsute ppc64el: universe/libdevel/optional/100% -> main
...

Is this likely to get backported to 20.04 or will it only be fixed from 21.04 onwards?

Hi, I am a maintainer of a low latency audio application, Mixxx. I misunderstood the prior discussion on this issue and thought that Ubuntu 21.04 would be shipping with PipeWire by default for audio. However I tested 21.04 beta in a VM and pipewire and pulseaudio are both running by default. It seems that PulseAudio is still used by default and PipeWire is only used for video on Ubuntu currently. Is that correct?

It seems there is no easy way for Ubuntu users to replace PulseAudio or JACK with PipeWire. I found this page on the Debian wiki:
https://wiki.debian.org/PipeWire#Using_as_a_substitute_for_PulseAudio.2FJACK.2FALSA
but I'm unclear if it's easy for Ubuntu users to prevent the PulseAudio daemon from running so PipeWire can take its place.

Are you planning to use PipeWire for audio by default by the 22.04 LTS release? I really hope by that by that time we can ship a Flatpak and have it just work by default on every common distro.