Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Red Hat dropping support for LibreOffice

lwn.net

Post reply on HN
Print view View original

261–270 of 316 posts

Re: Red Hat dropping support for LibreOffice

#261

Post by Gigachad »

wheelerof4te wrote: post #240
Gigachad wrote: post #33

Earlier quoted context omitted.

This is probably how things will be moving. It doesn't make sense for every single distro to maintain customized versions of user level applications now that we have one package that works everywhere.

"It doesn't make sense for every single distro to maintain customized versions of user level applications" Why it needs to be a customized package? Software is software and every Linux application which is open-source can be compiled and placed in /usr/local or whatever non-system level directory. Why is it so hard to compile the latest supported version and package it in a distro-agnostic way?

It isn't that hard, that's exactly what flatpak is doing.

Re: Red Hat dropping support for LibreOffice

#262

Post by wheelerof4te »

Gigachad wrote: post #261
wheelerof4te wrote: post #240

Earlier quoted context omitted.

"It doesn't make sense for every single distro to maintain customized versions of user level applications" Why it needs to be a customized package? Software is software and every Linux application which is open-source can be compiled and placed in /usr/local or whatever non-system level directory. Why is it so hard to compile the latest supported version and package it in a distro-agnostic way?

It isn't that hard, that's exactly what flatpak is doing.

Flatpak requires runtimes, not libraries. Most devel libraries don't take up GBs of disk space as Flatpak runtimes do.

Also, Flatpak apps are containerized. That usually means they aren't bare metal.

Re: Red Hat dropping support for LibreOffice

#263

Post by tredre3 »

redprince wrote: post #206
microtonal wrote: post #47

Earlier quoted context omitted.

This isn't some untrusted unauditable binary blob from a possibly shady manufacturer. 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 macO…

> It is a program that reads unstrusted binary blobs 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.

Why do you keep moving the goalposts?

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?

Re: Red Hat dropping support for LibreOffice

#264

Post by superkuh »

ho_schi wrote: post #178
Gigachad wrote: post #33

Earlier quoted context omitted.

This is probably how things will be moving. It doesn't make sense for every single distro to maintain customized versions of user level applications now that we have one package that works everywhere.

Because there are pros and cons for each type of packaging but native distro packages and Flatpak will go-exist. It does already on my machine. Distribution packages: + necessary for base system + small memory requirement + small package size + all checked by distro + work well together + on fix, fixes it for all o lot of work for maintainers downstream - bugs hard to figure out for upstream - problematic with closed…

The biggest minus of containers for me, including Flatpak, are that even with xdg desktop portal workarounds they still fail to actually integrate into the desktop and make or break features that depend on this simply don't work. And because it's a container it's nigh impossible to debug and find a fix. In the end containers are even more fragile than depending on system libs and fighting future shock.

Re: Red Hat dropping support for LibreOffice

#265

Post by pmoriarty »

raverbashing wrote: post #205
pmoriarty wrote: post #71

Earlier quoted context omitted.

What's more important for most users, document editing or image/video editing?

Wayland/HDR etc is much more important for those who need it than using LibreOffice (which still will be available) when there are plenty of online solutions that work fine

They work fine if you don't give a shit about your privacy.

Re: Red Hat dropping support for LibreOffice

#266

Post by g8oz »

pmoriarty wrote: post #84
noobermin wrote: post #69

I get libreoffice is "bad" but the existence of alternatives online really drive home how it is not impossible to develop a modern office suite alternative to office. I honestly wish I could have a desktop tool again, I'm tired of giving the large IT corps more data they can train on. It's possible with some love. Blender did it, it is quickly becoming an accepted tool in 3D graphics circles, if not the standard.

How is Libre Office bad exactly? It has always seemed like an excellent alternative to Microsoft Office to me. What don't you like about it?

Excel has raced ahead with LET()/LAMBDA() functionality and a JavaScript api. It seems that Libreoffice Calc has stood still in comparison (although to be fair it does feel more stable and responsive).

Re: Red Hat dropping support for LibreOffice

#267

Post by jzb »

kaba0 wrote: post #239
jzb wrote: post #227

Earlier quoted context omitted.

I really don’t see how this comment is relevant to the conversation at hand. None of this is about sandboxing libreoffice. It’s simply about a delivery method of getting a libreoffice on a system. Nix is absolutely 1000% not a mainstream solution that’s better than Flatpak for this. If your hobby is tinkering with Nix and marveling at its supposed technical superiority, more power to you. It is absolutely not relevan…

If I start up a nix shell with libreoffice installed within it, I will reliably get the same configuration the packager intended — so it is as relevant as it gets: if packaged correctly it will work on every system where tool X is installed. I just replaced X=flatpak with nix.

I see the goalposts have moved again, now we're on "reliably get the same configuration...."

The conversation is about Red Hat not packaging LibreOffice for RHEL. The options in scope here are RPM or Flatpak. Nix isn't even under consideration. You jumped in to complain about not being happy with Flatpak because it's not good at sandboxing. Nobody brought up sandboxing until you waded in about Nix.

It's tedious how any conversation about anything remotely related to packaging or pretty much anything, somebody has to show up stanning for Nix.

Re: Red Hat dropping support for LibreOffice

#268

Post by yjftsjthsd-h »

seabass-labrax wrote: post #217
dralley wrote: post #211

Earlier quoted context omitted.

Flatpaks unlike Snaps are actually sandboxed properly.

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?

Re: Red Hat dropping support for LibreOffice

#269

Post by Gigachad »

blablabla123 wrote: post #245
criddell wrote: post #34

Earlier quoted context omitted.

I think this is a small step in the right direction. IMHO, Flatpak (and similar schemes) with strict sandboxing should be the only distribution method for user applications. If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. If you want to give that application access to everything your user has access to, that’s fine, but it s…

It's all open-source and auditable, so any odd application behaviour should be prevented in the first place. Sandboxing is great but cgroups are not a sandbox. I think the post shows also that the main problem is amount of maintenance for many distributions. Maybe better package tooling would help - in the end Flatpaks are just a middleway between completely integrated packages and distributing everything as a self-c…

Multiple layers of security. Yes in theory I could audit millions of lines of C++ code to see that LO does not access the microphone, but I also like that the sandboxing layer prevents it from happening entirely. I'd rather audit a permissions list than an entire codebase.

Re: Red Hat dropping support for LibreOffice

#270

Post by Gigachad »

redprince wrote: post #209
bzzzt wrote: post #91

Earlier quoted context omitted.

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

> Compressed source code archive is over 300Mb. 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.

It's C++, the whole thing is interesting security wise.
Post reply on HN