Will it be replaced by some other office suite? As a non rhel user I don't get it
Red Hat dropping support for LibreOffice
281–290 of 316 posts
Re: Red Hat dropping support for LibreOffice
#282Earlier quoted context omitted.
As far as I know, Flatpak offers a fair amount of control over sandboxing. It's just that isn't particularly useful for some thing like a document processing application that you usually want to be able to use on files in various parts of your system. The alternative might be giving it access to one particular directories, and then copying files there when you want to work on them. But that's already pretty cumbersom…
> It's just that isn't particularly useful for some thing like a document processing application that you usually want to be able to use on files in various parts of your syste The good news is there is a solution to this. The trusted system shows a file picker, and then grants access to the sandboxes application. This is called the File Chooser Portal. https://docs.flatpak.org/en/latest/portal-api-reference.html...
I didn't realize this existed, it seems a lot like what Apple is doing for the photo gallery in recent iOS versions. That's a nice extra safety feature.
I suppose additional security features inspired by mobile systems couldn't hurt either. Like a pop-up whenever something accesses the clipboard.
Re: Red Hat dropping support for LibreOffice
#283Earlier quoted context omitted.
So only people capable of auditing source code and build scripts are able to be maintainers of opensource packages for others.
Perhaps you missed the part about not needing distro-specific packagers by providing a way to run third party apps without having to trust third party packagers. You can deny access to the camera or filesystem or network without ever auditing the source code and trust that the software cannot misbehave in that aspect. This isn't a knock on the value of package managers or maintainers. It's just an obvious step in bet…
We could have both though. They aren't mutually exclusive. Also important is the option to intercept system calls and return fake data to the software. Give it a silent audio, black video, a limited view of the file system. That lets us control proprietary software that gets pissy when permissions are denied.
Re: Red Hat dropping support for LibreOffice
#284Earlier quoted context omitted.
Flatpak is a non-starter for me. The runtimes required by my office would mean 2 KDE versions and 2 Gnome versions installed as flatpak runtimes in addition to the KDE running on the host, which quintuples the security space I need to monitor. Sweeping package management problems under a rug doesn't actually make them go away.
What do you mean by "monitoring security spaces"? Are you frequently refreshing the bug boards of every library your applications and OS uses?
I'm a sysadmin, and that's a big part of the job, yes.
Re: Red Hat dropping support for LibreOffice
#285Earlier quoted context omitted.
What do you mean by "monitoring security spaces"? Are you frequently refreshing the bug boards of every library your applications and OS uses?
Not all. But I'd wager it's not uncommon for a lot of linux people to periodically check their most used software with the largest attack surfaces. Browsers, document viewers/editors, mail clients, decompressors etc.
I mean, I don't do it for my home computer, but I do it for the fleet of computers I manage at work because someone gives me money to do that.
Re: Red Hat dropping support for LibreOffice
#286Earlier quoted context omitted.
Flatpak is a non-starter for me. The runtimes required by my office would mean 2 KDE versions and 2 Gnome versions installed as flatpak runtimes in addition to the KDE running on the host, which quintuples the security space I need to monitor. Sweeping package management problems under a rug doesn't actually make them go away.
Not sure which package problems are swept away according to you? You mean possible issues with library reuse, devendoring, etc? Besides, why 2 KDE AND 2 Gnome versions would be needed. The 'minimal' freedesktop would most likely suffice.
Do you use flatpaks? Each application brings with it a desktop runtime (Gnome or KDE or sometimes just the FDo that underlies Gnome and KDE), and each of those desktop runtimes is versioned. The problem is these don't get updated on Flathub at the same time, so the vector art editor brings one version of Gnome and the IDE brings a different version of Gnome.
Now, it's possible to build my own flatpaks and keep everything updated, but if I'm doing that I might as well just build the actual software and use the distro's package management system.
Re: Red Hat dropping support for LibreOffice
#287Earlier quoted context omitted.
What do you mean by "monitoring security spaces"? Are you frequently refreshing the bug boards of every library your applications and OS uses?
I'm very interested in some sort of daemon that regularly scans for vulnerable binaries/libraries and produces desktop notifications about this and/or hosts a web interface to review issues. I do use clamav for malicious files, but bug advisories/vulnerabilities are another area I wish I could make convenient to monitor for personal computing. I've seen things like Splunk reports in enterprise settings, but not for p…
Every SIEM does something like that, but somebody has to actually look at the screen and take actions based on it, and that's what my job is.
Re: Red Hat dropping support for LibreOffice
#288Earlier quoted context omitted.
Full or no filesystem access is very, very far from proper sandboxing.
As far as I know, Flatpak offers a fair amount of control over sandboxing. It's just that isn't particularly useful for some thing like a document processing application that you usually want to be able to use on files in various parts of your system. The alternative might be giving it access to one particular directories, and then copying files there when you want to work on them. But that's already pretty cumbersom…
That's roughly what our workflow does (DFARS requires it or something like it for CUI) and this story annoys me because the entire selling point of RHEL (which is what we use) is that you aren't having to audit a bunch of random upstreams because they do it for you. It's why their going all-in on flatpak was such a surprise to a lot of us.
Re: Red Hat dropping support for LibreOffice
#289Earlier quoted context omitted.
Just being sandboxed though isn't a help if you actively want the software to process sensitive data! If you want to read a private document in LibreOffice, you have to be sure your copy of LibreOffice and every library it calls is trustworthy and reasonably secure.
I dunno, if it's sandboxed and doesn't have network access then the only attacks I can think of are either really indirect (embedding an attack in saved files in hopes of hitting another user) or really targeted (altering a specific document or phrase when it's read). Assuming the sandbox works and includes blocking of network access, what attack do you see a word processor performing even when handed sensitive data?
Suppose your word processor is allowed to write to arbitrary files in your home directory. It writes a line into your .profile that CURLs your sensitive data to it's server.
This has a level of indirection, but that just delays things until the next login. With a little more work there are infinite other places you could inject that might run sooner.
Re: Red Hat dropping support for LibreOffice
#290Earlier quoted context omitted.
Just being sandboxed though isn't a help if you actively want the software to process sensitive data! If you want to read a private document in LibreOffice, you have to be sure your copy of LibreOffice and every library it calls is trustworthy and reasonably secure.
I dunno, if it's sandboxed and doesn't have network access then the only attacks I can think of are either really indirect (embedding an attack in saved files in hopes of hitting another user) or really targeted (altering a specific document or phrase when it's read). Assuming the sandbox works and includes blocking of network access, what attack do you see a word processor performing even when handed sensitive data?
You're ignoring the supply chain side.
RHEL RPMs are signed by Red Hat. Flatpaks are signed by... whoever happens to maintain that flatpak.