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

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

undeadly.org

Post reply on HN
Print view View original

321–330 of 339 posts

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

#321

Post by gtk40 »

LeoPanthera wrote: post #90
elagost wrote: 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.

KDE also has Konqueror, which now allows you to use either KHTML or WebKit as the rendering engine. KHTML works fine on simple sites like Hacker News nowadays but chokes on newer ones often.

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

#322

Post by zrm »

jcelerier wrote: post #200
zrm wrote: post #153

Earlier quoted context omitted.

It's really trading one problem for a different one. The reason traditional distributions only package one version of a given library and make everything use that same version is so they only have to maintain one version of the library. If you allow every application to choose its own version then they all choose a different one, which means someone then has to continue to maintain every different version of the libr…

> If you allow every application to choose its own version then they all choose a different one, which means someone then has to continue to maintain every different version of the library separately. Well, no. Else software on macOS and Windows obviously wouldn't work, since those ship all their libraries along. It does not matter to the users of my software that I use libraries versions X, Y, Z, what matters is tha…

> Well, no. Else software on macOS and Windows obviously wouldn't work, since those ship all their libraries along.

Not exactly. For the system libraries (e.g. the Windows crypto API) you effectively get one version for the whole system, and it works because the library maintainer (Microsoft) is diligent about maintaining backwards compatibility between versions. Whereas for applications that include their own copy of e.g. OpenSSL, that problem does occur there. When there is a vulnerability discovered in OpenSSL, every developer using it has to update their application instead of a library package maintainer doing it once, and if any application is no longer maintained (or just never updated to the latest version) it's now insecure indefinitely.

> And it is so much more painful to ensure that it will work correctly without any regression and with best performance for every version across e.g. Qt 5.6 to 5.14, than to just ship Qt 5.14 myself built with only the features I want with all my use cases duly tested.

You don't have to ensure it works with every version ever made, only the one the distribution ships.

This is made much easier if the library developer designates specific versions as stable and then stable distributions use those versions, because then working against the two or three actively maintained stable versions is all you need to work anywhere.

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

#323

Post by zrm »

avar wrote: post #164
zrm wrote: post #153

Earlier quoted context omitted.

It's really trading one problem for a different one. The reason traditional distributions only package one version of a given library and make everything use that same version is so they only have to maintain one version of the library. If you allow every application to choose its own version then they all choose a different one, which means someone then has to continue to maintain every different version of the libr…

It doesn't entail any of that. Traditional distributions like Debian allow you to install any number of library combinations, they just do so badly by requiring you to do so on different installations updated at different times. Supporting the presence of multiple library combinations doesn't mean that you "support" all version combinations in the sense of supporting all combinations of their versions being used in t…

> Supporting the presence of multiple library combinations doesn't mean that you "support" all version combinations in the sense of supporting all combinations of their versions being used in the wild.

It's not about combinations. It's about, there's a serious bug in the library and now there are 79 different actively used versions of it that need to be patched instead of 2, which means half of them never get fixed.

> You'll get the same bugs, but users can easily back out say an OpenSSL version with a security fix for the 5% of packages it breaks with, while retaining the fix for their browser & other high-risk packages.

You'll get the same bugs and then the 5% of packages a security update breaks are broken until they're fixed, which should happen promptly because broken packages should be very high priority. Is it really better in that short time for the other 5% of applications to "work" but be insecure and get your system compromised because the new vulnerability is being actively exploited?

The real solution is for sufficient testing to be done during the embargo period so that by the time the new version goes wide it doesn't actually break anything.

> For example, I currently can't upgrade my firefox version on Debian testing because it ">=" depends on a version of a couple of libraries that some 100-200 other packages on my system don't like.

Right, that's a problem. It's valid to need version >= 5.6 of some library, but something has gone wrong if some other package specifically needs version 5.5 -- version 5.6 should be able to satisfy that dependency. Or if it can't then "5.6" should be 6.0 and it should be possible to have 5.x and 6.x installed together, but that should happen only rarely so that at most two or three mutually incompatible versions are in active use at once.

In general the latest version should be able to satisfy applications expecting older versions and then you need only a suitably recent version and nothing else, and the lack of that is the real issue.

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

#324

Post by avar »

zrm wrote: post #323
avar wrote: post #164

Earlier quoted context omitted.

It doesn't entail any of that. Traditional distributions like Debian allow you to install any number of library combinations, they just do so badly by requiring you to do so on different installations updated at different times. Supporting the presence of multiple library combinations doesn't mean that you "support" all version combinations in the sense of supporting all combinations of their versions being used in t…

> Supporting the presence of multiple library combinations doesn't mean that you "support" all version combinations in the sense of supporting all combinations of their versions being used in the wild. It's not about combinations. It's about, there's a serious bug in the library and now there are 79 different actively used versions of it that need to be patched instead of 2, which means half of them never get fixed.…

> It's not about combinations. It's about, there's a serious bug in the library and now there are 79 different actively used versions of it that need to be patched instead of 2, which means half of them never get fixed.

Yes I agree that would be a royal pain in the ass, i.e. running something like a Debian where each package would be the equivalent of a docker image with an individual maintainer who'd need to decide when they upgrade OpenSSL.

I'm saying you could have something like a Debian where the build infrastructure and package maintenance works exactly the same, your package is always built against the latest library versions.

But users get a NixOS-like experience where they can partially update their system, now with traditional OS package management an update of a common library & a full system-update are often in practice the same thing.

> Is it really better in that short time for the other 5% of applications to "work" but be insecure and get your system compromised because the new vulnerability is being actively exploited?

On the flip side is it really better that if you're using the other 95% of applications that your security fix is delayed because upstream is finding it a pain to rebuild the patched package for 5% of its users? That's realistically the alternative.

> [...]but that should happen only rarely so that at most two or three mutually incompatible versions are in active use at once[...]

The sum of differing versions in use among a distro's userbase is vastly larger than that, some of those users are deferring security updates because their distro makes upgrading an all-or-nothing experience.

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

#325

Post by jcelerier »

zrm wrote: post #322
jcelerier wrote: post #200

Earlier quoted context omitted.

> If you allow every application to choose its own version then they all choose a different one, which means someone then has to continue to maintain every different version of the library separately. Well, no. Else software on macOS and Windows obviously wouldn't work, since those ship all their libraries along. It does not matter to the users of my software that I use libraries versions X, Y, Z, what matters is tha…

> Well, no. Else software on macOS and Windows obviously wouldn't work, since those ship all their libraries along. Not exactly. For the system libraries (e.g. the Windows crypto API) you effectively get one version for the whole system, and it works because the library maintainer (Microsoft) is diligent about maintaining backwards compatibility between versions. Whereas for applications that include their own copy o…

> and it works because the library maintainer (Microsoft) is diligent about maintaining backwards compatibility between versions.

yet people have to ship microsoft DLLs left and right since behaviour sometimes still break. One breakage is enough to convince stakeholders to do that.

> When there is a vulnerability discovered in OpenSSL, every developer using it has to update their application instead of a library package maintainer doing it once, and if any application is no longer maintained (or just never updated to the latest version) it's now insecure indefinitely.

On the other hand, I had software who broke, as in, core features became unoperational due to openssl distro updates and changes of default policies. My users much prefer having working potentially unsafe software in the exceptional case where the software would connect to the network (eg reading a youtube stream in VLC or something like that) that non-working software.

> You don't have to ensure it works with every version ever made, only the one the distribution ships.

Which is "every version ever made" because people are still rocking Debian Wheezy or Ubuntu 12.04 and want to use my software

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

#326

Post by Carpetsmoker »

kevin_thibedeau wrote: post #273
Carpetsmoker wrote: post #239

Earlier quoted context omitted.

The problem isn't so much that Debian packages or the ecosystem "breaks" as such, but that you run in to bugs (sometimes already fixed ones), and that you're then basically stuck with that unless you, the maintainer, or someone else decides to backport the fix, and they frequently don't get backported especially not for "minor" bugs.

Just compile it yourself and put it in /usr/local.

Well, yeah, but that's bypassing the package manager. You can say that in response to pretty much every argument about "I don't like package manager X because Y".

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

#327

Post by int_19h »

inferiorhuman wrote: post #162
int_19h wrote: post #76

Earlier quoted context omitted.

Python 2/3 is not a representative example, because it's actually designed to be installed side-by-side by the authors. Many libraries and apps on Unix are not. NixOS changes a lot of things to make it all work. If you're willing to pay that tax for the sake of package management, great! People who use BSDs generally aren't.

Python 2/3 is not a representative example, because it's actually designed to be installed side-by-side by the authors. Many libraries and apps on Unix are not. Rust is designed to support multiple toolchains with rustup. I've got the following installed on my desktop box: stable-x86_64-apple-darwin nightly-2018-12-14-x86_64-apple-darwin nightly-arm-unknown-linux-gnueabihf nightly-x86_64-apple-darwin (default)

If I remember correctly, the granularity for this mechanism is pretty much arbitrary - i.e. you can have 1.2.3 and 1.2.4 installed side by side if you wanted to. From a practical perspective, if this means that the apps can start depending on 1.2.3 specifically, it requires the distro to package every minor version separately, which is very time- and space-consuming. With gcc and clang it's easier, because usually only the major versions get packaged side by side, and minor versions are simple upgrades.

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

#328

Post by shakna »

celticmusic wrote: post #316
shakna wrote: post #312

Earlier quoted context omitted.

> If I'm faced with a major upgrade of an LTS system, I usually choose to reinstall from scratch, shedding packages I haven't needed for a long time with it. But that happens every couple years or so. This goes back to my original point, which we've drifted a little from. Ubuntu has more unexpected behaving when upgrading than Debian. A working dist-upgrade should not be something that your OS struggles to provide. A…

it's called LTS for a reason. Just don't dist-upgrade, problem solved. This argument that you MUST dist-upgrade as soon as the next version is available, and completely ignore the entire idea around LTS, is silly.

> This argument that you MUST dist-upgrade as soon as the next version is available, and completely ignore the entire idea around LTS, is silly.

This idea that you never want to upgrade from one LTS to the next is equally ridiculous. Upgrading the operating system is part of the package manager's job.

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

#329

Post by jrockway »

strictfp wrote: post #196
jrockway wrote: post #166

Earlier quoted context omitted.

I agree. I also think that large projects should just vendor their dependencies, including compilers, so you git clone the thing, type "bazel build", and have a working binary. (I am fine if the dependencies are not checked in to the repository, a bazel WORKSPACE file is fine with me. It records a checksum for all dependencies, so even if you reach out to the Internet to get it, you get the same bytes as the develope…

Sure, that gives you working binaries. But also security problems, because you don't control which versions of libraries you are using. Suddenly, all individual software packages must do their own security updates to keep the system secure. So the whole thing is a balance.

You do control what version of libraries you're using. You include the exact SHA256 of every dependency of every dependency, down to the toolchain itself.

If you're saying "your distribution can't automatically update you if libc is vulnerable to something", that's true. More CPU time is required to react to major vulnerabilities, as everything has to be recompiled. However, it's not much CPU time, and the downsides of requiring more compute time are lower than the upsides of knowing exactly where your dependencies come from. And having your "getting started" instructions be "1) install bazel 2) bazel run //your:binary".

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

#330

Post by progval »

jcelerier wrote: post #325
zrm wrote: post #322

Earlier quoted context omitted.

> Well, no. Else software on macOS and Windows obviously wouldn't work, since those ship all their libraries along. Not exactly. For the system libraries (e.g. the Windows crypto API) you effectively get one version for the whole system, and it works because the library maintainer (Microsoft) is diligent about maintaining backwards compatibility between versions. Whereas for applications that include their own copy o…

> and it works because the library maintainer (Microsoft) is diligent about maintaining backwards compatibility between versions. yet people have to ship microsoft DLLs left and right since behaviour sometimes still break. One breakage is enough to convince stakeholders to do that. > When there is a vulnerability discovered in OpenSSL, every developer using it has to update their application instead of a library pack…

> My users much prefer having working potentially unsafe software in the exceptional case where the software would connect to the network (eg reading a youtube stream in VLC or something like that) that non-working software.

Do they, though? Or are they just unaware of what "insecure" means?

Sure, if you frame it as "[technobabble about TLS certificates], click 'continue' to make the software work?", they'll chose the insecure-but-working option.

But if you frame it as "your Internet Service Provider, government, and possible third-parties may be notified you are watching this video, do you want to proceed?", some of them might think twice, depending on what country they live in and what the video is.

Post reply on HN