PipeWire 0.3.31 Released With Better JACK Support, More Crash Fixes

[ssokolow]

Actually no, there is little to no difference in that regard. On the other hand, when running the Teams client in a flatpak sandbox, THEN I can control what it has access to, and especially ensure that it can't touch any of my browser data.

You can always run Teams in its own profile and, if you want, run that under Flatpak... but Flatpak doesn't currently support fine-grained network access-control as is embodied by the Same Origin Policy, so a compromise could be used to do stuff like attacking your WiFi/Ethernet-attached printer (your printer vendor does still provide security updates for your printer, I hope?) or your IoT devices or your router's admin interface. (You do check for and apply updates to your router firmware, I assume?)

Granted, the Same-Origin Policy isn't as robust as a proper Flatpak-level application firewall set to deny access to non-routable IPs would be (I still need to figure out which repo to file that feature request on), but neither of the two mechanisms is a strict subset of the other.

[aorth]

You realise that the web app you run on Chromium runs locally and is, for the most part, the same JS code as the standalone client (which is based on Electron)?

Yes I know, but they don't get to run any code outside the browser. No secret updaters (remember Chrome on Linux had its own updater?), no monkey business like reading shit from my environment or seeing what apps I have installed/active, etc. It's like the push for web applications like Reddit, Twitter, Facebook where they pressure/force you to install the app instead of using it from a browser. They want you to install it so they can fuck around reading your contacts, GPS, Bluetooth, apps, etc. (Remember Twitter was found guilty of sending the list of your installed applications on Android back to the mother ship).

Did you see this Orwellian shit about Teams tracking your screen, focus, etc?

https://www.wired.co.uk/article/micr...g-data-privacy

More practically, the native app sucked with HiDPI on Sway, but the browser app is crisp as of recent Chrome with Ozone support.

[mppix]

You can always run Teams in its own profile and, if you want, run that under Flatpak... but Flatpak doesn't currently support fine-grained network access-control as is embodied by the Same Origin Policy, so a compromise could be used to do stuff like attacking your WiFi/Ethernet-attached printer (your printer vendor does still provide security updates for your printer, I hope?) or your IoT devices or your router's admin interface. (You do check for and apply updates to your router firmware, I assume?)

Granted, the Same-Origin Policy isn't as robust as a proper Flatpak-level application firewall set to deny access to non-routable IPs would be (I still need to figure out which repo to file that feature request on), but neither of the two mechanisms is a strict subset of the other.

I don't think the goal here is to limit Team's internet/network access but the data that it has access to on the local machine.
Former is nontrivial in general but the latter is solved with flatpak.

[ssokolow]

I don't think the goal here is to limit Team's internet/network access but the data that it has access to on the local machine.
Former is nontrivial in general but the latter is solved with flatpak.

Given that I have to trust the browser to keep me safe on random websites as a matter of day-to-day living (granted, I normally use uMatrix and the like), I much prefer running the browser version of apps like that, Flatpak or not.

...and running multiple profiles isn't trivial but it's not exactly complicated. I do it just so I don't have to loosen up the restrictions on my regular profile that break PayPal's new popup-based checkout flow.

That said, I am working to migrate as many GUI apps as possible to Flatpak (and to tighten the permissions they come with where possible) and investigating the possibility of running CLI tools through Wasmer, WAPM, and wax, since that provides a nice "whitelist to $PWD by default" baseline that can serve as "like Flatpak but for terminal workflows".

...and I've been meaning to take full advantage of systemd's built-in support for sandbox restrictions.

(I'll probably write some launcher wrappers to use Firejail for whatever I can't do with those options.)

[mppix]

Given that I have to trust the browser to keep me safe on random websites as a matter of day-to-day living (granted, I normally use uMatrix and the like), I much prefer running the browser version of apps like that, Flatpak or not.

...and running multiple profiles isn't trivial but it's not exactly complicated. I do it just so I don't have to loosen up the restrictions on my regular profile that break PayPal's new popup-based checkout flow.

That said, I am working to migrate as many GUI apps as possible to Flatpak (and to tighten the permissions they come with where possible) and investigating the possibility of running CLI tools through Wasmer, WAPM, and wax, since that provides a nice "whitelist to $PWD by default" baseline that can serve as "like Flatpak but for terminal workflows".

...and I've been meaning to take full advantage of systemd's built-in support for sandbox restrictions.

(I'll probably write some launcher wrappers to use Firejail for whatever I can't do with those options.)

I think it is debatable if installing proprietary (Teams, spotify, etc.) apps in flatpack or running them in a browser is 'better'. I straight out refuse to install any proprietary app with root permissions. To me that is equivalent to handing them the machine.
Often, I end up with a flatpak install but running them in a browser on flatpak may be even better.
Some apps still have issues with flatpak, like zoom-flatpak screen-sharing in wayland is still broken.

Other than that, I'm starting to make flatpak apps my default install process and I don't really see drawbacks: you tend to get the latest versions (big deal on Debian stable for example), more security, theming integration is often better, and it does not require much/any effort from the user.

[ssokolow]

Other than that, I'm starting to make flatpak apps my default install process and I don't really see drawbacks: you tend to get the latest versions (big deal on Debian stable for example), more security, theming integration is often better, and it does not require much/any effort from the user.

I generally agree but there are hiccups here and there.

Some examples:

• Geeqie refuses to pick up the Flatpak-provided copy of the Breeze widget theme for whatever reason. (All my other GTK Flatpak apps Just Work™ on that front.)
• Flatpak explicitly does not intend to provide first-class command-line support, so I'd never be able to use Calibre through Flatpak, since I only ever use it by scripting the ebook-convert CLI tool.
• I keep the APT-distributed version of DOSBox for various test automation scripts that wouldn't know to pass the necessary --filesystem flags. (Hopefully, WASI won't take too long reach a point where a WASI build of DOSBox can be made and distributed via wax's CLI-friendly "share $PWD by default" paradigm.)
• There are various other apps that are on Flathub, which I currently use from the Kubuntu 20.04 LTS repositories while I'm waiting for various sandboxing-caused feature regressions to be tracked down and solved.
• I have yet to see how support will be added to web browsers for File Chooser Portal-like behaviour when double-clicking or dragging-and-dropping a file:// URL outside the Flatpak sandbox, so I have to keep one browser unconstrained for that.

[mppix]

I generally agree but there are hiccups here and there.

Some examples:

• Geeqie refuses to pick up the Flatpak-provided copy of the Breeze widget theme for whatever reason. (All my other GTK Flatpak apps Just Work™ on that front.)
• Flatpak explicitly does not intend to provide first-class command-line support, so I'd never be able to use Calibre through Flatpak, since I only ever use it by scripting the ebook-convert CLI tool.
• I keep the APT-distributed version of DOSBox for various test automation scripts that wouldn't know to pass the necessary --filesystem flags. (Hopefully, WASI won't take too long reach a point where a WASI build of DOSBox can be made and distributed via wax's CLI-friendly "share $PWD by default" paradigm.)
• There are various other apps that are on Flathub, which I currently use from the Kubuntu 20.04 LTS repositories while I'm waiting for various sandboxing-caused feature regressions to be tracked down and solved.
• I have yet to see how support will be added to web browsers for File Chooser Portal-like behaviour when double-clicking or dragging-and-dropping a file:// URL outside the Flatpak sandbox, so I have to keep one browser unconstrained for that.

Can you elaborate why command-line and flatpak don't work well. I mean it is a little less convenient but once one gets used to executing
'flatpak run org.inkscape.Inkscape' instead of 'inkscape', it works just as well.
Of course, 'inkscape' itself is just a link to the installed executable and can also be configured to execute the flatpak command.

Totally agree to the file access from browser. Currently, the only options are to either copy your files in a folder accessible by the browser (usually just ~/Downloads) or to blow the sandbox wide open.
However, I think this is being considered..

[jo-erlend]

I use Pipewire as default audio server since 0.3.30 on Ubuntu 21.04 and all works fine. Finally I don't have to suspend PulseAudio for enable JACK for simple thing like a recording via Audacity. Even Audacity from Flatpak works fine (recording of multiple tracks never worked fine for me before use of Pipewire).

I have a Zoom H6 recorder, which has multiple inputs and I've tried to use it with Audacity, but only got one input. Do you think this might solve that? That would be so very cool! You really got my pulse going now.

[oiaohm]

Flatpak explicitly does not intend to provide first-class command-line support, so I'd never be able to use Calibre through Flatpak, since I only ever use it by scripting the ebook-convert CLI tool.

https://github.com/flathub/com.calibre_ebook.calibre/issues/30

People have got the ebook-convert working with the "flatpak run --command=ebook-convert com.calibre_ebook.calibre" the problem was a runtime issue why it would fail covered in the bug report above. Please note this was also resulting in convert failures with the complete calibre graphical open as well.

Flatpak does include support to use command line tools from flatpaks its not not the most friendly beast all the time due to the sandbox restrictions resulting in needing to pass the right allow flags so stuff works

Sandboxing I do agree is bringing it fair share of problems. That drag and drop is something else that needs to be solved.

[pal666]

The only problem I've had is that MS Teams doesn't work with PipeWire.

i use teams with pipewire without issues