OpenBSD won't update Firefox, advises users to switch to ESR • Hacker News Board

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

#91

Post by snazz » Sun, Jan 12, 2020, 12:57 AM UTC

fooqux wrote: post #77

microcolonel wrote: post #60

Earlier quoted context omitted.

I mean, it is a key advantage, on ArchLinux. If you don't have a rolling release, it's pure pain: you're often just stuck with old versions of software which aren't any more stable than the current stable release.

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 unstable" thing hasn't been true for a long time. I find that it's far more stable than Debian or Ubuntu LTS on my machine because of newer kernels containing newer hardware drivers.

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

#92

Post by jcranmer » Sun, Jan 12, 2020, 12:57 AM UTC

app4soft wrote: post #74

elagost wrote: post #40

Earlier quoted context omitted.

If I'm to avoid Firefox, I'd like to avoid its forks as well - they don't really improve upon anything meaningful both of those have had more issues than Firefox in the past. I'm thinking smaller than Firefox.

> 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 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), if you are worried about any security issues in Firefox, moving to such a fork should only worry you more.

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

#93

Post by cesarb » Sun, Jan 12, 2020, 12:58 AM UTC

offmycloud wrote: post #38

floatingatoll wrote: post #24

Earlier quoted context omitted.

RedHat’s “streams” model will certainly do a much better job of handling this than the other distributions do today. I hope that the need for having multiple parallel versions of a dependency coexist is incorporated into the other distros, because I’ve lost a lot of sanity this past two decades to the assumption that “one installed version should be enough for anybody” on Linux and BSD servers.

I hope so, but Fedora is dragging their feet putting out a patched Firefox package on Fedora 30, which is still suppoted.

You can check the status for the firefox package in Fedora at https://admin.fedoraproject.org/updates/ which shows firefox-72.0.1-1.fc30 as "testing" (that is, you can install through "yum --enablerepo=updates-testing update firefox"). The reason for it not being promoted to stable yet is, according to that page, "disabling automatic push to stable due to negative karma" - that is, the update was marked as broken by a couple of people.

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

#94

Post by hoistbypetard » Sun, Jan 12, 2020, 1:01 AM UTC

Analemma_ wrote: post #47

sandov wrote: post #41

Earlier quoted context omitted.

I'll go one step further: The whole "centralized, trusted repository that has all your apps" system is wrong at a fundamental level. The way shared libraries are used in Linux is built upon the assumption that package managers and centralized repositories are the right way to do things.

I agree, and I think that people are too emotionally invested in the package manager concept to back out now. I mean, for years Linux proponents have been touting it as the key advantage over software distribution on Macs/PCs.

The existence and popularity of homebrew, macports and fink (on mac) and ninite, chocolatey, cygwin, mingw and nuget (on windows) would suggest that the concept appeals to mac and windows users also.

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

#95

Post by AdamJacobMuller » Sun, Jan 12, 2020, 1:01 AM UTC

asveikau wrote: post #18

jszymborski wrote: post #17

Earlier quoted context omitted.

"presumably small security patch" The security patch is actually quite severe and has been reported to be in active use. https://www.mozilla.org/en-US/security/advisories/mfsa2020-0... https://www.cisecurity.org/advisory/vulnerability-in-mozilla...

I meant small as in code size. In a stable branch you want the size of changes to be small and targeted despite how severe the issue is. You don't want to take on new bugs from patches that aren't related to issues you want to see fixed.

If the change is so small, I don't see why they wouldn't be able to backport the fix? Don't upgrade firefox (and any dependencies), just fix the bug.

It would be a lot harder if the actual fix was more complicated and a much more complicated diff. Possible that master has diverged sufficiently from their version that backporting the fix would be unreasonable.

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

#96

Post by snazz » Sun, Jan 12, 2020, 1:02 AM UTC

archi42 wrote: post #87

jolmg wrote: post #81

Earlier quoted context omitted.

> What you lose is access to the "latest and greatest", because it takes time for the new stuff to filter in. Depends on the distro. Archlinux is pretty fast to update packages.

This! Our company OpenSUSE Tumbleweeds were still vulnerable on Friday. On Arch, the package was already available for two days then. The thing is, the distro maintainers need to decide whether they want a fast moving "latest and greatest" approach, which might break stuff by accident, or go a "slow but always dependable" route, which you can depend on as company, with painful losses if things go south (in which case…

As I mentioned downthread, surprisingly little stuff breaks by accident nowadays on Arch (on my desktop, zero breakage in the last year with a fairly complex stack; on one server machine I had one strange interaction between a language package manager and pacman that ended up being my fault). The "slow but dependable" solution ends up breaking as soon as software becomes too complex for maintainers to be able to backport security fixes onto old versions, so they just ship the latest version of those packages, negating the dependability aspect (like Debian's treatment of Firefox and Chromium).

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

#97

Post by zozbot234 » Sun, Jan 12, 2020, 1:03 AM UTC

int_19h wrote: post #72

zozbot234 wrote: post #50

Earlier quoted context omitted.

Outside packages should NOT be disrupted given semver. The whole point of using shared objects (dynamically-linked libraries) is so that when a problem arises you can update whatever pieces of code in a centralized, system-wide store and every single one of the projects you use can benefit from the new, up-to-date version. Using the latest version is just the right thing to do.

Semver is not a given in practice. Many libraries haven't adopted it, some of those that claim to break things in practice, and the very definition of a "breaking change" can mean different things - sometimes depending on the consumer (this is especially true for cross-language interactions).

Distributions can make their own choices about versioning if upstreams "break" semver. Sometimes this results in weird version strings and you might not want to depend on these relabeled system packages for your own projects - that's the one case where "vendoring" a dependency version might be worthwhile. But it ought to be quite rare indeed.

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

#98

Post by hoistbypetard » Sun, Jan 12, 2020, 1:03 AM UTC

ChickeNES wrote: post #37

blackhaz wrote: post #14

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…

I wish NeXTsteps's app bundles had caught on outside of OSX.

Me too. Especially as combined with fat binaries in the OS X rosetta years. It'd make it a lot easier to package something that would run on arm, arm64 and amd64 in a more accessible way for users.

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

#99

Post by jolmg » Sun, Jan 12, 2020, 1:05 AM UTC

archi42 wrote: post #87

jolmg wrote: post #81

Earlier quoted context omitted.

> What you lose is access to the "latest and greatest", because it takes time for the new stuff to filter in. Depends on the distro. Archlinux is pretty fast to update packages.

This! Our company OpenSUSE Tumbleweeds were still vulnerable on Friday. On Arch, the package was already available for two days then. The thing is, the distro maintainers need to decide whether they want a fast moving "latest and greatest" approach, which might break stuff by accident, or go a "slow but always dependable" route, which you can depend on as company, with painful losses if things go south (in which case…

It's perhaps coincidental, but I don't remember ever having a trouble on an update that I couldn't find a quick fix for in the Archlinux homepage.

In my opinion, the reason why Archlinux can be so dependable is that packaging is based on really simple ideas, like not starting or stopping services on installation like Ubuntu would, and that most if not all system files belong to a package. The package manager can do a whole OS installation just by installing the basic packages on a directory different from /. The package format is also really simple. Getting into the guts of Archlinux packaging is really approachable and that makes me feel at ease for whatever trouble I may find myself in.

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

#100

Post by mantap » Sun, Jan 12, 2020, 1:11 AM UTC

The problem seems to be one of command line interface.

In the C/C++ world, you specify the language version using a flag passed to the compiler. e.g. -std=c++98

In most other programming languages, you specify language version by installing multiple copies of the compiler/interpreter and running the corresponding version.

The C/C++ way works fine if your language spec is updated once every 3 years. It does not work fine for anything much more frequent than that. Until recently C and C++ were popular enough that the other approach didn't need to be accommodated. Now it does.