Slackware 13.37 and 14.0 presently have firefox 17.0.11 ESR and neither have had any updates since Nov 2013 (although mozilla-nss etc have, don't know if that is relevant). However in slackware 14.1, once firefox 24 ESR reached "end of life" it was upgraded to firefox 31 ESR.

Now we all like to be vigilant with respect to security etc. But does this mean that we should be discouraged from using firefox in versions 13.37 and 14.0, since they haven't been updated for so long?

If the version of firefox in slackware 14.1 had stayed at version 24 ESR then I guess I wouldn't be wondering this, but since it was updated it slightly concerns me that the versions in 13.37 and 14.0 have not been. Perhaps they don't have all the necessary libraries etc.?

Does anyone have any comments that might dispel/confirm my concerns?

Cheers,

Michael

If I remember rightly, it was exactly that. I believe this issue was why Pat swapped to using ESRs in the stable releases in the first place, but eventually even ESRs go EOL.


Upgrade to 14.1 would be my advice.

2 members found this post helpful.

michaelslack,
FWIW (which is a lot IMO), forum member ruario has produced an invaluable script which allows us to download the latest Regular -or- ESR version of Firefox (you must edit the script to point it to ESR):
http://www.panix.com/~ruari/latest-firefox
You can run this script as normal user, then as root run upgradepkg on the package which ends up built under /tmp/

Running FF 31.4.0 ESR here on 14.0 with no problems!
Thank you ruario!!!

4 members found this post helpful.

The latest version is here:

https://gist.github.com/ruario/9672798 (though I have just updated the one on panix as well).

My newest version let's you auto-install via the '-i' switch, though you need to run it as root to do that.

Also you don't need to edit it. It you want ESR, set the variable FFESR to "Y", e.g.:

P.S. You are welcome STDOUBT

3 members found this post helpful.

I would also do the following:

and add 'export FFESR=Y' to '~/.bashrc' or another suitable location.

1 members found this post helpful.

You can also set your preferred language, via a variable. For example, I have 'export FFLANG=en-GB' in my '~/.bashrc'. Choose between any of the following: ach, af, ak, ar, as, ast, be, bg, bn-BD, bn-IN, br, bs, ca, cs, csb, cy, da, de, el, en-GB, en-US, en-ZA, eo, es-AR, es-CL, es-ES, es-MX, et, eu, fa, ff, fi, fr, fy-NL, ga-IE, gd, gl, gu-IN, he, hi-IN, hr, hu, hy-AM, id, is, it, ja, kk, km, kn, ko, ku, lg, lij, lt, lv, mai, mk, ml, mr, nb-NO, nl, nn-NO, nso, or, pa-IN, pl, pt-BR, pt-PT, rm, ro, ru, si, sk, sl, son, sq, sr, sv-SE, ta-LK, ta, te, th, tr, uk, vi, xpi, zh-CN, zh-TW, zu

1 members found this post helpful.

Thanks GazL, STDOUBT and ruario for the quick helpful responses. Also thanks ruario for the extra tips re: running your script, I will give them a go.

That's very interesting. I came across reference to ruario's script when searching the forum for similar threads. My understanding is that the script rebundles the binary release mozilla provides into a slackware package. These bundles contain a bunch of shared libraries, but on the "install firefox on linux" support page it mentions that certain other libraries are also needed for the resultant firefox to run.

It would appear then that these runtime dependencies are satisfied by slackware 14.0. However it may be that there are buildtime dependencies needed to build those bundled shared libraries missing from stock slackware 14.0, and this is why the firefox in slackware 14.0 (and 13.37) has not been updated beyond 17.0.11 ESR; it cannot be built on the system.

Whatever the reason, it is still slightly disconcerting for me that this is the case. I use slackpkg to keep all my various machines (two older pentium 4's running 13.37, one laptop running 14.0, my main system running 14.1 and another laptop running -current) up to date and have (mindlessly) assumed that as long as I run slackpkg whenever the ChangeLog.txt is changed I would be keeping each of these systems "secure", at least until the corresponding release is EOL'd. It has taken me (who is reasonably familiar with slackware) a long time to realise this firefox issue, so I wonder if many people are using an older release as a desktop with firefox the preferred browser? If so it seems to me that they are exposed to some vulnerabilities (please correct me if I am wrong).

Perhaps there is a case for updating firefox in these older releases using ruario's method rather than leaving them at 17.0.11 ESR? Bear in mind too that since 13.37 Pat has put in /extra a slackbuild for building a slackware package for (the partly closed-source) google-chrome by rebundling a .deb binary package which a user could in principle rebuild each time there is a chrome update.

What do people think? Maybe I'm off the mark with some of my assumptions? There may be other reasons why this is how it is...

Michael

Perhaps a wider perspective might ease your mind.
I'm going with the statement GazL made regarding libraries. In this case, it might be unreasonable to expect a "lone" distro maintainer to impose potentially sweeping changes to the system-at-large for the sake of one application, especially knowing that the moderately skilled user can easily work around the issue. Of course, other distributions will have different modus operandi...

In considering that some build-time libs for newer FF may not be present on the older Slackware versions, I doubt highly this would affect the "security" of the application itself. Someone more knowledgeable might speak to this but it sounds right to me.

One thing Slackware is known for is offering software in as close to a "vanilla" state as possible. Being charged with self-managing stuff like this FF issue is another thing that sets Slackware and its users apart.

michaelslack, you mentioned your use of slackpkg to keep your system up-to-date. I hope you're not too shocked to learn that none of the third-party packages (SBo,etc.) that you have installed are touched by slackpkg update. Updating those is, again, self-management. But this is what Linux is to many people! "Cobbled together" some say. In some cases, Slackware's case IMO, the term "crafted" fits better.
Firefox is just a browser, after all. It can take care of itself. It's downloadable. We can run it. Phear the Penguin!

Bottom line, for myself at least, is that it is generally trivial to install and run whatever latest (or not) software one would like on Slackware. Slackware may not make things easy (by resolving deps for instance), but it certainly allows us to make things easy. I sure hope that last line makes sense to you :^)

Maybe I'm missing something in this thread?

You do realize, that you don't need to install firefox "into the system". You can just download firefox into your user home directory and extract it. Then launch with a link to ~/firefox/firefox. You can then install flash by creating a "plugins" directory in ~/firefox/browser (~/firefox/browser/plugins), then copy libflashplayer.so into it.

firefox 35 works on slackware 13.37 64 doing just that.

If I mis-understood your post, I apologize. Just FYI.

Thanks coldbeer and STDOUBT for your responses.

coldbeer: Yes I'm aware of this, indeed right now I'm using the latest FF in the manner you describe on slackware 13.37. The reason for my post was more of a general discussion point rather than a single personal issue. However there are use cases where ruario's method would be preferable to this e.g. if the system has multiple users, then it would probably be better to install it system-wide and as a proper slackware package.

STDOUBT: There are various "user cases" among slackware users, including keen hobbyists who just love getting their hands dirty and playing with their system to their heart's content but also including those who are as busy as hell and just want their system to work and work reliably with minimal fuss. On the whole in my experience slackware has catered very well to both these extremes. On my main system I take the latter approach. I use slackpkg+ with some packages from alienBOB (flashplayer-plugin, vlc, etc) and also sbopkg to keep the SBo stuff up to date. There are very few packages which need to be maintained "manually" (although in the past I did use to take a more hands-on approach). Just subscribing to the slackagg RSS feed alerts me to any updates in either slackware itself, alienBOB's repos or SBo and then I just run slackpkg and sbopkg. In particular all necessary security updates are incorporated as they appear.

Now I know that the slackpkg+ extension and all of SBo are "not official". However slackpkg is and in Pat's welcome email he refers to it as his favourite way to keep the system up to date, which one might reasonably assume includes all necessary security updates. If someone was content to just use a vanilla slackware system (some may do so!) and use slackpkg to keep it updated then that should incorporate all necessary security updates. Even putting slackpkg aside, if a user subscribed to the slackware security updates mailing list and manually updated each package mentioned there, they would still (possibly?) end up with a vulnerable browser. This just seems to be a bit "out of character", at least what I've come to perceive as the character of slackware.

Now, whether or not one agrees with this, the obvious next question is "well what do you propose be done about it"? There are a few options I've touched on earlier in the thread, but in summary some options (in increasing order of complexity) are (for the slackware team) to

1. do nothing;
2. provide an updated binary package built using ruarios rebundling method;
3. build such a binary package from scratch, perhaps on another (more up-to-date) system which satisfies all buildtime dependencies;
4. completely update all necessary buildtime dependencies and build a binary package on the same system.

Now as STDOUBT points out the last option is most certainly asking too much of the slackware team. The second option while the quickest and easist solution would be unusual in that as far as I know, Pat usually doesn't distribute packages including binaries he hasn't built (although I may be wrong; in fact there must be some like this e.g. kernel firmware which is not open source...) and indeed there may be some subtle licensing issue with doing this. However the third option may not be too taxing (perhaps just build it on a newer slackware system?).

Another possibility is to

• Put a script like ruario's in /extra and
• if a binary package of the latest firefox (ESR or otherwise) is not available (for whatever reason), advise
  (via the security mailing list) that users update their firefox using that script.

Of course, all of this is moot if it turns out that firefox 17.0.11 ESR is not vulnerable...

Cheers,

Michael