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

201–210 of 316 posts

Re: Red Hat dropping support for LibreOffice

#201

Post by hakfoo »

criddell wrote: post #34
thesuperbigfrog wrote: post #30

Flatpak will be the recommended way to get / install LibreOffice on RHEL and Fedora. In https://lists.fedoraproject.org/archives/list/devel@lists.fe... it states: "the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term." Install instructions are already written: https://acces…

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…

That tends to wave away the responsibilities of the distributor.

The distributor's job is to package software. In effect, putting it in their repo is sort of vouching for it-- they know it's going to work properly with the rest of the repo, and be built with whatever standards the distribution offers (i. e. Debian being sensitive to IP concerns, Clear Linux doing its shiny performance optimizations, etc.)

If you just hand everything off to external self-contained images, you lose a lot of that.

I suppose you could do 'captive' collections of Flatpaks, designed to meet the same optimization and compatibility promises, but at that point, you have RPMs with extra steps.

Taken to an extreme, a Flatpak-centric distribution ends up looking a lot like Windows, where there's no useful tools on the distribution media and a new install is followed by hours of clicking through third-party installers (or permissions consent dialogue boxes maybe) or devolving trust to scripts that promise to do it for you.

To an extent, I also just resent the entire "it works on your machine? We'll ship your machine" mentality-- Docker/Kubernetes and Flatpaks/Snaps are sort of variations on the same theme. They come from a mindset of infinite free resources-- the disc space for all those redundant dependencies is coming from somewhere-- and it would seem to make brittle, hacky code more viable because you don't have to FIX code that depends on unguaranteed aspects of an API contract.

Re: Red Hat dropping support for LibreOffice

#202

Post by pjmlp »

creatonez wrote: post #151
pjmlp wrote: post #132

Earlier quoted context omitted.

Where is the desktop product? https://www.redhat.com/en/technologies/all-products I see cloud, OpenShift, SAP, embedded, servers, desktop not really.

Their desktop products are Red Hat Enterprise Linux Workstation, Red Hat Edge, and the Red Hat Universal Base Image build system. The former is used heavily in particle physics laboratories (CERN and Fermilab use a mix of RHEL, Alma, CentOS) as well as some niche graphics workstations. The latter two are used for a lot of different things, but can be used to manage automatically-updating company-assigned desktops/lap…

CERN researchers mostly use Windows and macOS, even if the LHC cluster is powered by Linux.

Back in 2003 - 2004, I was one of the few in my group, ATLAS/TDAQ, that bothered to have a laptop with Scientific Linux, and I doubt it has changed.

All of those projects are a by product that Red-Hat Enterprise Linux also needs a graphical user interface, not a desktop product on its own.

Re: Red Hat dropping support for LibreOffice

#203

Post by barbariangrunge »

Dumb questions:

To clarify, is libreOffice a red hat project? Does this mean the project needs a new maintainer? Or is this saying that the red hat distro is no longer ensuring compatibility (in favor of a different product?)? If they're just dropping support from the distro, what are they replacing it with?

Re: Red Hat dropping support for LibreOffice

#204

Post by pjmlp »

htag wrote: post #161
pjmlp wrote: post #60

Earlier quoted context omitted.

Anyone that is mildly evolved with SecDevOps knows how much of theory that happens to be in practice.

I'm unsure what your talking about. Surely SecDevOps would be mostly alerted when a vulnerability isn't caught by someone looking at OSS. Those vulnerabilities that are caught should be mostly invisible.

Pentesting is also part of it.

Re: Red Hat dropping support for LibreOffice

#205

Post by raverbashing »

pmoriarty wrote: post #71
trop wrote: post #68

The OP is burying the lede! The exciting news [0] is > We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what’s needed for color-sensitive work, and a host of other refinements required by Workstation users. This is a long-standing and important effort [1] to make Wayland more plausible for image/video-editing. [0]: https://lw…

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

Re: Red Hat dropping support for LibreOffice

#206

Post by redprince »

microtonal wrote: post #47
redprince wrote: post #43

Earlier quoted context omitted.

> If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. 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…

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.

Re: Red Hat dropping support for LibreOffice

#207

Post by kpw94 »

torstenvl wrote: post #123
MereInterest wrote: post #105

Earlier quoted context omitted.

And AppImage distribution has the same fundamental security problem as static binaries, making it difficult or impossible to replace downstream dependencies. When a dynamic library needs a security update (e.g. heartbleed in libssl), the shared library can be replaced system-wide. When a static executable or AppImage needs a newer version of a library, you need to update the program entirely, and there is no way to d…

And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected. But on a system where everything is updated at the same time through a package manager, I don't see that there's a material difference, unless you as the upstream app developer decide not to build against the latest security updates of your dependencies; but if that's the case, that's a completely separa…

> And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected

What's more common in practice ? Widely used libraries introducing critical vulnerabilities in 2023. Or old vulnerabilities being discovered/exploited, and patched?

> unless you as the upstream app developer decide not to build against the latest security updates of your dependencies; but if that's the case, that's a completely separate issue from dynamic vs. static linkage.

That's precisely the problem isn't it? What if "You the upstream app developer" is on a long vacation, or abandoned the project? Multiply this by N where N is the number of different app developers.

Compare with "you as the OS admin". If you're using your system, you update that vulnerable dynamic library, and you're done.

If users of other machines are on vacation or abandoned their machine, that's not your problem. Your system is secure.

So I feel parent's point had everything to do with dynamic vs. static linkage.

Re: Red Hat dropping support for LibreOffice

#208

Post by dralley »

supportlocal4h wrote: post #107
dralley wrote: post #77

Earlier quoted context omitted.

The former has tons of plausible alternatives which are already more frequently used than LibreOffice - and of course you can still use LibreOffice via Flatpak anyways. The latter is a hard requirement to doing serious media editing work on Linux regardless of what software you want to use. And unlike the former, there's a dedicated customer base that wants it.

There were plenty of plausible alternatives before Sun bought StarOffice and made it Free software. There were plenty of plausible alternatives when the Libre folks "freed" LibreOffice from Oracle. LibreOffice is still the standard-bearer for open source office suites. It isn't competing with WordPerfect or AmiPro or Lotus 1-2-3 or Quattro Pro like it used to. The proprietary stuff have largely died and lost to the t…

Nobody is getting rid of LibreOffice, it's only a question of whether it is supported directly by Red Hat as part of the base install and repos.

Re: Red Hat dropping support for LibreOffice

#209

Post by redprince »

bzzzt wrote: post #91
redprince wrote: post #43

Earlier quoted context omitted.

> If I install LibreOffice, I want to be asked for permission before it tries to access my microphone or location or other sensitive resources. 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…

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

Post reply on HN