
OpenBSD won't update Firefox, advises users to switch to ESR - jackhalford
https://undeadly.org/cgi?action=article;sid=20200109141600
======
blackhaz
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 - once in a while I have to say "screw
it" and auto-update more than a thousand packages, praying my Python and other
projects survive, just because I want a browser update or a security fix.

I wonder if there are others who support this opinion that desktop Unix has
very complicated future unless complex apps will begin to bundle their own
libraries.

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

~~~
Qerub
AppStream does not allow installation of multiple versions of the same app
AFAIK. I believe this is what they refer to in the clumsy sentence "The one
disadvantage of Application Streams from SCLs is that no two streams can be
installed at the same time in to the same userspace. However, in our
experience, this is not a common use case and is better served using
containerization or virtualization to provide a second userspace." in the
linked article in the sibling comment.

~~~
floatingatoll
Ugh, I did not understand that. I'm so sorry. If I could edit my post to
retract it, I would. The NixOS comments from others should still be valid.

------
aquabeagle
The title on this story makes it sound like OpenBSD stopped updating Firefox
altogether. That's not the case, it just stopped backporting non-ESR Firefox
updates to its -stable branch.

------
smartmic
> being too complicated to package (thanks to cbindgen and rust dependencies)

Can anyone explain what is behind? Is it symptomatic for any programs with
those dependency? Especially curious about rust because it seems to be hyped
very much lately (I have almost zero rust experience and even less bias about
it, just being curious)

~~~
asveikau
They don't want to need to update Rust in order to do a presumably small
security patch on Firefox.

Which honestly sounds like a totally awesome and legit reason to use -esr.
Keep -current current with upstream, stable branch gets patches from firefox-
esr.

Keep in mind stable patches to the ports tree are pretty rare on OpenBSD. They
didn't do them as binary packages until fairly recently, either.

~~~
jszymborski
"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.mozilla.org/en-
US/security/advisories/mfsa2020-03/)

[https://www.cisecurity.org/advisory/vulnerability-in-
mozilla...](https://www.cisecurity.org/advisory/vulnerability-in-mozilla-
firefox-could-allow-for-arbitrary-code-execution_2020-004/)

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

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

~~~
danieldk
_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._

As far as I understand, you cannot call it Firefox anymore if you deviate from
upstream (which is understandable, because upstream doesn't want to get bug
reports for custom changes):

[https://www.mozilla.org/en-
US/foundation/trademarks/distribu...](https://www.mozilla.org/en-
US/foundation/trademarks/distribution-policy/)

------
notaplumber
> OpenBSD-current users are not affected, www/mozilla-firefox update is
> already committed and will be available soon on the mirrors.

------
ArcVRArthur
OpenBSD-current users are not only NOT affected by this, actually they just
got Pledge and Unveil support in Firefox 71. [https://marc.info/?l=openbsd-
ports-cvs&m=157539245010077&w=2](https://marc.info/?l=openbsd-ports-
cvs&m=157539245010077&w=2)

If you don't know about Pledge and Unveil you can think of it as similar to
Firejail sandboxing from Linux but on steroids. It dynamically limits the
types of kernel calls and filesystem addresses a process can make use of so if
a rogue thread causes a process to perform an illegal operation under the
Pledge rules OpenBSD will kill the process with SIGTERM. Whats more Pledge and
Unveil allow the process to execute whatever calls are needed when the program
initializes itself but it will relinquish the privilege to run those calls for
the remainder of the program's runtime once it no longer needs them (after
init).

------
throwaway838475
The whole modality of a single package in a single configuration at a single
version is broken and dead dependency-hell of yesteryear. Still, ports and
packages collections mechanically and unthinkingly continue this failed and
broken modality of wasted effort. Packaging multiple versions and multiple
configurations side-by-side similar to Habitat (hab) and Nix independent is
the only way to go. This approach supersedes vendored dependencies because it
allows garbage collection and sharing of identical dependencies rather than
duplicating them. Furthermore, it allows real choices without an either-or and
real real flexibility that single recipes that always attempt to track a
rolling version can never possibly achieve.

Also broken is maintaining multiple packages that package multiple versions of
the same package with combinations of external, frequently changing platform
packages like rubygems that are packaged manually. Multiple versions of the
same package should share common recipe declarations as much possible and be
managed more cleanly. Native extensions should be built automatically in CI/CD
using polling or notifications rather than manual methods that too often lead
to outdated, vulnerable dependencies and create too much pointless,
repetitious busywork.

------
dathinab
So basically:

\- Firefox is hard to package so they won't package it (on stable).

\- OpenBSD-current users are not affected as firefox has already been
committed.

\- Firefox-ESR is still maintained.

> (thanks to cbindgen and rust dependencies) on the stable branch (as this
> would require testing all rust consumers)

Can someone explain what they mean with this? What have other non firefox rust
consumers to do with firefox being packaged?

The best guess I have is that to package firefox they need to package cbindgen
and rust. And if they package cbindgen and rust officially all packages using
it would now need to be tested as now (potentially) all their dependencies
have been packaged?? But this seems strange TBH.

EDIT: So I guess they still will package Firefox-ESR on stable? Which will
have (or maybe already has) all that dependencies, too? So it's just about
having to do that packaging less often?

~~~
floatingatoll
It appears that they are unwilling to update to the latest Rust-stable release
due to the testing burden on the OpenBSD-stable team; which then conflicts
with the Firefox Rust update policy of, as I read it, ‘latest Firefox stable
will use latest Rust stable’.

[https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox](https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox)

~~~
dathinab
Ok thanks, I guess this is somewhat understandable.

Through I wonder a bit why they don't automate the tests (maybe the
computation cost?). (E.g. rust automatically runs the tests of all
libraries/programs published on crates.io to find regressions, through that
takes a day or so to complete).

~~~
anjbe
Okay, suppose someone backporting a Rust update runs a big batch of tests and
finds, say, two dozen packages with regressions.

Now what?

Spend two weeks investigating all the test failures? Backporting updates to
these packages as well, all while users are patiently waiting for their
Firefox to have its zero‐day fixed? Are the tests even correct? Were they
failing before and nobody noticed?

And all this to only get _automated_ tests passing. Any regressions in
behavior not tested are not noticed (or more likely, noticed by users much
later, requiring further investigation at that point in time to narrow down
the Rust backport as the cause).

In the meantime, this packager’s work on other OpenBSD packages in -current
(what most OpenBSD developers actually use day‐to‐day) completely stops.

That’s some insight into the mindset of a software packager. Non‐security
backports to language runtimes are a serious maintenance burden.

~~~
zozbot234
> Okay, suppose someone backporting a Rust update runs a big batch of tests
> and finds, say, two dozen packages with regressions.

> Now what?

> Spend two weeks investigating all the test failures? Backporting updates to
> these packages as well, all while users are patiently waiting for their
> Firefox to have its zero‐day fixed? Are the tests even correct? Were they
> failing before and nobody noticed?

Yes, people do exactly that. It's part of running a "rolling" distro, see e.g.
the Debian Testing transition tracker at
[https://release.debian.org/transitions/](https://release.debian.org/transitions/)
\- These transitions are running essentially all the time; they're only "put
on hold" as a first step in the process of making a new stable release. And
even then, newer versions of packages such as rust can still enter stable as
part of an "unrelated" security update.

~~~
anjbe
> Yes, people do exactly that. It's part of running a "rolling" distro

And we do that too—for OpenBSD -current. But we have neither the manpower nor
the interest to do such work for _old releases_.

~~~
fluffything
There are many options to solve that:

* switch to a shorter stable release cycle (4 weeks, 6 weeks, etc.) with dynamic releases (e.g. if a zero day happens, fix current, and do a new stable release)

* switch to only supporting -current

* switch to something like Nix to allow stable users to "switch" some packages from stable to current, without having to bump their whole system (this would have allowed stable users to update their Firefox-stable to Firefox-current)

A good packaging process should not assume that downstream packages can be
trusted to have meaningful processes. Relying on Firefox having -esr releases
is a temporary workaround.

------
mijoharas
For anyone else that wasn't aware, ESR[0] stands for extended support release,
so an older Firefox that still has security patches back ported (like Ubuntu
LTE I guess)

[0] [https://support.mozilla.org/en-US/kb/switch-to-firefox-
exten...](https://support.mozilla.org/en-US/kb/switch-to-firefox-extended-
support-release-esr)

------
newnewpdro
Can't the required rust version be (temporarily) treated as part of firefox
then, and not bother building everything else using rust with that version?

~~~
floatingatoll
It seems likely the OpenBSD would consider such a patch if it were presented
to them, but they might also reject it due to ideals they hold that outsiders
can’t predict.

------
elagost
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?

~~~
app4soft
_Waterfox_ (with Web Extensions) or _Pale Moon_ (with XUL/UXP extensions)

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

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

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

~~~
the_why_of_y
It's similar in Rust, you specify the language edition with a line in
Cargo.toml.

[https://doc.rust-lang.org/nightly/edition-
guide/editions/cre...](https://doc.rust-lang.org/nightly/edition-
guide/editions/creating-a-new-project.html)

~~~
umanwizard
Rust language editions are not similar to C++ standard versions.

Every new version of the Rust compiler brings changes to the language, so the
language you're actually using depends on the tuple (compiler version,
edition), not just on the edition.

~~~
the_why_of_y
Rust language editions are similar but not equivalent to C++ standard
versions, because compiling code written for an old edition with a new edition
is not guaranteed to work, due to breaking language changes like new keywords.

But you are correct to point out that old Rust editions will get new language
features _if_ they do not break existing code.

[https://hacks.mozilla.org/2018/12/rust-2018-is-
here/](https://hacks.mozilla.org/2018/12/rust-2018-is-here/)

The release process claims that the changes in new Rust releases are purely
additive and backward compatible; the only exception is soundness fixes, which
I'd expect affect a negligible amount of code.

~~~
umanwizard
> compiling code written for an old edition with a new edition is not
> guaranteed to work, due to breaking language changes like new keywords.

This is not at all similar to C++ standards, and the specific case being
discussed in this post demonstrates exactly why!

Barring bugs in implementations, developers could develop against whatever
version of the compiler they like, and as long as it supports the same
language version, distro or OS maintainers wouldn’t have to update theirs, and
everything would work.

I worked on an open-source project that targeted C++11. It could build on
basically any Linux distro you can imagine, even ones with very old versions
of GCC. (it didn’t support BSD, but for unrelated reasons).

This is the point the Rust project seems to miss when harping on about
backwards compatibility: forwards compatibility is just as important.

~~~
the_why_of_y
Okay, I see what you mean; I guess if I were a Rust programmer I'd solve that
by using rustup to install a fixed Rust release for development.

However the Firefox project has decided to always require the latest stable
Rust release.
[https://news.ycombinator.com/item?id=22022834](https://news.ycombinator.com/item?id=22022834)

In practice for C++ I've found it expedient to whitelist some subset of
functionality from newer standards, because there's often useful features that
already work in the major 3 compilers, but it'll be another 3 years until the
last of the compilers adds the last obscure bits for full support of the new
standard.

------
floatboth
This is why FreeBSD doesn't do "stable ports" tied to a system release
version. Stable ports are a very bad idea.

------
floatingatoll
(nope! wrong! deleted)

~~~
brynet
No, Mozilla does not distribute Firefox binaries for OpenBSD.

~~~
floatingatoll
Thanks, sorry :(

------
OrgNet
they should make an effort, since this is Firefox...

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

~~~
thenewnewguy
The "fancy update policy" being 'latest FF stable uses latest rust stable',
which seems like a pretty reasonable policy to me.

~~~
cbmuser
I disagree. The compiler is normally something that receives major updates in
every new distribution release. That's why language specs exist for.

If you are maintaining a large number of machines in an enterprise
environment, you're not keen on updating half of the installed system just
because you update your browser, simply because the necessary testing and
fixing of regressions costs a lot of time and money for no real gain for both
users and administrators.

~~~
hashhar
You can have multiple Rust toolchains side by side. This is a non-issue in
that case. If there's some other usecase that this breaks, I'd like to know
about it and see if we can do something to improve the scenario.

~~~
umanwizard
The point is that, despite it being possible theoretically, the OpenBSD
project does not want to take on the maintenance burden and additional clutter
of having 40 (!) separate versions of the compiler toolchain in the ports tree
with a new one landing every 6 weeks.

