This isn't some untrusted unauditable binary blob from a possibly shady manufacturer. Everything it will or will not do is right there for everyone to see in the published source code from which it is compiled and packaged.
Furthermore nothing is fundamentally stopping anyone to apply SELinux policies to this application just like a flatpak would.
It is a program that reads unstrusted binary blobs (many document formats) using C++ deserialization code that has a history tracing back to the nineties and even eighties (through StarOffice). I sure as hell want such an application to be sandboxed and ask for elevated permissions. This is pretty normal on other platforms like macOS (Office and iWork from the Mac App Store run sandboxed), iOS, and Android.
Furthermore nothing is fundamentally stopping anyone to apply SELinux policies to this application just like a flatpak would.
You need more than policies. E.g. if a program cannot read outside its sandbox, you need some way to mediate access to files/directories on the user's request, which are provided by e.g. Flatpak/XDG desktop portals.
When opening any office files from unknown or untrusted sources is something you feel you have to do, you're probably well off isolating that operation and thus limit the blast area.
For people working exclusively on their own files or with trusted colleagues, that is pretty much a non issue.
First you say that people should just audit the code if they don't trust it. Then you say if someone wants to read untrusted files they should just spin up a virtual machine?
So I need to spend thousand of hours reading libreoffice's and its dependencies' code, and then I still need to run it in a virtual machine when I read untrusted files (in case there are bugs that could be exploited)?
It makes zero sense to keep pushing that nonsense when the alternative is to sandbox apps to begin with. It makes EVERYBODY safe from backdoors and bugs, for FREE. Why do you fight it?
Because of an intended functionality of many of those file formats, which makes them quite dangerous when coming from untrusted sources: Macros.
Compressed source code archive is over 300Mb. That's not a manageable amount for one individual, so I wouldn't expect it to be systemetically reviewed.
Much of it not interesting security wise.
> That's not a manageable amount for one individual, so I wouldn't expect it to be systemetically reviewed.
I settle for people thinking like attackers and going for the attack surfaces.
Sandboxes should be the must in this century and mobile OSs are much more ahead here.
I audit some of it sometimes. I trust that other do the same. Many hands make light work.
I also enjoy stracing random programs in order to figure out the exact set of system calls they're making, in which order and with which parameters.
This isn't a knock on the value of package managers or maintainers. It's just an obvious step in better security. It seems silly to argue that integrity among package maintainers is the only safeguard we need. I personally like the little piece of plastic that my laptop has that slides across the built-in camera. It's not a software solution, or even an electronic safeguard. It's even better than the little DIP switch on my phone. I say, why not?
I don't know about "deserve" but it's true that we have the knowledge necessary to understand what a script or program is doing.
> There should never be any other way to offer trustability?
Of course not. Someone else can audit it for you. If you trust that person, then you also trust the software that they audited.
Linux distribution packagers are the simplest example I can think of. If something makes it into a Linux distribution like Debian, it's pretty trustworthy. That's a big reason why we users like that model. It's also why developers hate it.