Audio production on Linux, using proprietary audio plugins, is somewhat funny/interesting to see in the context of security.
I mean, there are a lot of recent efforts to put applications in containers, sandboxes, lots of talking about X11 being unsafe vs Wayland...
And then users just download and run arbitrary binary code from the internet 😅
Nothing against those that do this, it is just a bit funny to see from a security perspective.
> Also that it's compiled from the exact same code that's available.
On that topic, the followong might be of interest
https://whatsrc.org/
https://reproducible-builds.org/
@macberg yes as I see it incompetence can happen equality on both sides. stuff that leads to hacks by accident.
malice is harder to do when the code is open though.
also, proprietary + commercial vendors much more often have analytics and other network related features vs opensource plugins, so I am then more skeptical of them in general. a plugin requiring libcurl is often a red flag for me.
@falktx Malice is harder, but very much not impossible. Look at the Deepin desktop for instance (I'm not saying they're malicious, but they very well could be, given how they've stubbornly kept introducing deliberate vulnerabilities, and no one seems to have noticed/cared except OpenSuse).
Libcurl is a good thing to point out. I hadn't even thought about that one myself, but it's quite obvious now that you mention it.
@amadeus I wouldnt be so sure...
My tests on https://github.com/falkTX/wayland-audio-plugin-test/ show it is possible, and based on that I could easily support wayland UIs in Carla (not the S1 spec though, please let's not do their proposal as it would complicate hosts job way too much)
afaik that repo contains the very first LV2 UI under wayland. granted it does nothing useful, but it does load with its own custom LV2 UI type
@amadeus also note that pugl (used by DPF and a few others) kinda already supports wayland, the code is "just" not public yet because it is also not ready and we need host support first
I think next year we will have our first LV2 wayland UIs, loadable within at least Carla and Qtractor.
@falktx I don't do music production but couldn't (shouldn't) hosts sandbox the plugins?
E.g. using https://landlock.io/
@pluto haha, I have bad news for you...
99% of DAWs and audio plugin hosts do no sandboxing or bridging.
But it's kinda expected, when we are dealing with 1000s of plugins that need to run in less than 0.5ms each. Dealing with context switching and thread sync across these many instances would waste time that could be better spent processing more plugins.
@falktx well then maybe rather sandbox the process as a whole. I'm getting somewhat curious to what the fallout would be of widely locking down say an Ardour (or maybe something simpler?) just before loading plugins.
No more arbitrary saving and loading files after that but it might make for a proof of concept.
From my understanding, the performance impact would be negligible, and only apply to those types of resource acquisition which landlock is actively filtering.
@pluto Bitwig does that, kinda. The engine is its own process and plugins go together with it, separate from the UI and session manager. This allows to protect against engine/plugin crashes. It's not really sandboxing though.
For true sandboxing flathub with audio plugins kinda does that right now, by loading plugins within that same sandbox. But it's quite inconvenient, apps from flathub do not see global/system-wide installed plugins (and if they do they break sandbox rules)
@falktx You're right, but I mean, open source can be just as dangerous as arbitrary binary code. The openness is only an *opportunity* for security, but you need enough competent people to look at the code for it to make a difference. Also that it's compiled from the exact same code that's available.
People who believe it's safe just because it's FOSS need to rise their guard a bit. Especially as Linux grows and becomes more of a target.