Live data from Hacker News

OpenBSD won't update Firefox, advises users to switch to ESR

undeadly.org

101–110 of 339 posts

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#101
post #22

Is there a better alternative to Firefox? Of all the browsers it seems like the "least bad" choice (above Chromium, and other proprietary browsers) and I use it, but is there something safer, simpler, and more secure?

Yes. Firefox forks that forked before Mozilla jumped the shark (v37, then multiprocess, then rust) that evolved into their own thing without all the features/attack surfaces that aren't strictly required for a browser to just render html and execute JS.

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#102
post #22

Is there a better alternative to Firefox? Of all the browsers it seems like the "least bad" choice (above Chromium, and other proprietary browsers) and I use it, but is there something safer, simpler, and more secure?

Suckless Surf may be the simplest one out there: https://surf.suckless.org/

It's basically a lightweight interface to webkit. There's only so light one can go, however; a browser basically ships an entire rendering stack and big chunks of an OS, and with all the weird features and backwards compatibility issues that have accumulated, one can only go so small.

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#103
post #22

Is there a better alternative to Firefox? Of all the browsers it seems like the "least bad" choice (above Chromium, and other proprietary browsers) and I use it, but is there something safer, simpler, and more secure?

GNOME has "GNOME Web", previously known as Epiphany. KDE has "Falkon". Both are quite good.

I'd still be seriously concerned about how few eyeballs they get with regards to security---Google has entire fleets of machines dedicated to fuzzing every line of Chromium code and both Chrome and Firefox use advanced sandboxing to make it so that a single exploit in the JavaScript engine wouldn't be able to result in user-level remote code execution. I'm sure they're both probably fine (if nothing else from security by obscurity) but modern browsers are complicated pieces of software that require a lot of engineering to keep secure.

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#104

Earlier quoted context omitted.

Waterfox (with Web Extensions) or Pale Moon (with XUL/UXP extensions)

If security is something you’re looking for, “Firefox plus some ancient, unmaintained legacy code and patches jammed in by random third parties” is not substantially more appealing than just Firefox by itself.

Your description does not apply to the two examples given. It's obvious you don't even know what they are even if you knew what they were 5 years ago. Look again.

Pale Moon and the like aren't just ancient Firefox code. And without all the 'features' Firefox keeps adding in that are irrelevant to a browser that renders html and executes JS they're just as secure.

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#105

I am arguing about this on FreeBSD forums - from an end user perspective. I think the benefits of saving disk space by sharing libraries do not justify the inconveniences we, desktop BSD and Linux users, obtain from being forced to disrupt and upgrade hundreds of installed software packages, just because one single desired upgrade requires to pull its dependencies. The whole ecosystem falls down like a card house - o…

> auto-update more than a thousand packages, praying my Python and other projects survive, just because I want a browser update

You may want to check out Nix. It's a package manager which isolates each program's dependencies; so you can have multiple versions of the same package.

> or a security fix

having a centralized repository like this helps in case a it's a library that needs a security fix, because you only need a single update to apply the fix to all applications. Applications that bundle their own deps (including Docker images) will need to publish their own update with the updated version of the lib.

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#106

Earlier quoted context omitted.

> they don't really improve upon anything meaningful both of those have had more issues than Firefox in the past. Please, prove it.

From looking at the commit history of Pale Moon, it is maintained by essentially three people. Their maintenance strategy is to freeze at an old version of Firefox, and randomly backport patches purely to try to keep somewhat up-to-date on JS or DOM features. Given the sheer size of the codebase, its inherent complexity (a JIT compiler is going to be very ripe for potential security vulnerabilities), and the utter la…

I not see any proofs here. Only your personal opinion.

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#107

Earlier quoted context omitted.

> they don't really improve upon anything meaningful both of those have had more issues than Firefox in the past. Please, prove it.

From looking at the commit history of Pale Moon, it is maintained by essentially three people. Their maintenance strategy is to freeze at an old version of Firefox, and randomly backport patches purely to try to keep somewhat up-to-date on JS or DOM features. Given the sheer size of the codebase, its inherent complexity (a JIT compiler is going to be very ripe for potential security vulnerabilities), and the utter la…

>utter lack of any sign of trying to mitigate these problems (e.g., fuzzing, or even merely attempting to identify security fixes in Firefox that may warrant backporting),

And here's where you show you're making it up and haven't even looked at a Pale Moon release notes, http://www.palemoon.org/releasenotes.shtml

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#108
post #22

Is there a better alternative to Firefox? Of all the browsers it seems like the "least bad" choice (above Chromium, and other proprietary browsers) and I use it, but is there something safer, simpler, and more secure?

Yes. Firefox forks that forked before Mozilla jumped the shark (v37, then multiprocess, then rust) that evolved into their own thing without all the features/attack surfaces that aren't strictly required for a browser to just render html and execute JS.

Simpler, sure. Safer and more secure, how? There's been a lot of new security features in Firefox recently that you'd be missing out on if you used something that old. You can't put "just" in front of "execute JS" (or "render HTML" for that matter); that's a pretty complex task with a lot of security concerns. I can't imagine that the communities of these Firefox forks can keep up with backporting upstream security fixes, especially since the modern Firefox codebase has diverged so much.

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#109
post #91
post #77

Earlier quoted context omitted.

It's only pure pain if you want bleeding edge AND stability. Non-rolling releases are just fine if you only need new features once a year.

Non-rolling releases might work with smaller software where your distro maintainers can backport security bugfixes easily, but as soon as your software gets too big and complicated the distro maintainers won't be able to backport fixes themselves and will have to just resort to packaging the latest version of certain packages (like Debian had to do with Chromium and Firefox). Also, for the most part, the "Arch is uns…

You can run backported kernels on Debian and Ubuntu LTS too. On the latter it's pretty much the default - they provide "hardware enablement" releases so that users can avoid issues on cutting-edge hardware.

Re: OpenBSD won't update Firefox, advises users to switch to ESR

#110
post #49

This is 100% is on mozilla, given: - it's much bigger and resourceful than openbsd maintainers. - it decided to adopt this fancy update policy, and instead of making it easy/seamless, left it up to the whole open source community to play catch up. Well played.

The "fancy update policy" being 'latest FF stable uses latest rust stable', which seems like a pretty reasonable policy to me.
Post reply on HN