The problem of Firefox in Ubuntu Breezy
| From: | Ian Jackson <iwj-AT-ubuntu.com> | |
| To: | ubuntu-devel-AT-lists.ubuntu.com | |
| Subject: | Firefox in Breezy (1.0.8), and security support | |
| Date: | Wed, 7 Jun 2006 15:54:43 +0100 |
I have been investigating the situation with firefox 1.0.8 in Breezy
given the presence of known security problems in 1.5.0.3 in Dapper
(for which we are planning to deploy 1.5.0.4 from upstream just as
soon as dapper-security is open).
The situation isn't very good, and none of our options look
particularly good. I thought I should report on what I have
discovered so that we discuss and decide what to do.
As I suspected,
1. The diff between 1.5.0.3 and 1.5.0.4 is very large and contains
many changes that could not be described as security or stability
fixes. It includes (just as an example) dozens of changes to files
which are not compiled or used in any sane configuration of firefox
1.5.0.3.
2. The code has changed very considerably between 1.0.8 and 1.5.0.3 in
many of the areas affected by the changes.
The effect of these two factors is to make it impractical to
selectively backport the 1.5.0.3->1.5.0.4 diff to our firefox.
The obvious alternative approach would be to try to identify in the
1.0.8 source the problems described by the CVEs and 1.5.0.4 release
notes, with the assitance of the 1.5.0.3->4 diff, and to craft new
fixes for 1.0.8 and release them in Breezy. This should be possible
in principle but obviously it's a lot of effort and for reasons I'll
go on to explain I don't think it's sufficient or necessarily the
right answer.
There are some other already-known facts that are relevant here:
3. We know that the 1.5.0.2->1.5.0.3 diff contained what look like
fixes to security problems not listed in the published release
notes nor in the CVE list provided to me by Martin.
4. Our firefox in Breezy contains a total of about 60klines of diff
even from upstream 1.0.8, including what amount to `backports' of
substantial pieces of i18n and rendering code (much of it present
only in Ubuntu and not in Debian). That is, early versions of some
changes were taken from the Mozilla Bugzilla and applied to our
browser. During the 1.5 merge for Dapper, I found that in general
the relevant functionality was included in 1.5, but in each case
1.5 had a newer implementation.
Together with the desupport upstream of 1.0.x, this means that
Breezy's Firefox has no security support from upstream and contains a
significant amount of code which has never been given security
support, nor released, by anyone else.
For upstream-supported versions this isn't true; the Mozilla
organisation is the best channel for reporting bugs in Mozilla
products and there is evidence that although their release and
documentation processes are poor, they do actually fix bugs.
Furthermore, as a highly visible and central player, they have a
reputation to maintain on this point.
So, the code our users are running is substantially different from any
code that has anything like a well-supported a mechanism for capturing
and dealing with reports of security problems. Indeed, if someone
discovers a vulnerability in Firefox 1.0.8 I have no confidence that
Mozilla would deal with it appropriately or that we would hear about
it.
So I think we have a problem and ought to be creative in our thinking
about this problem. Brainstorming, without ruling out any of the
options, I can think of at least the following options for Ubuntu:
- End support for Breezy.
- End security support for web browsing in Breezy with
some appropriately scary announcement.
- Attempt to address only known vulnerabilities (inventing new fixes
as described above) and hope that this is sufficient.
- Provide a version of firefox 1.5.0.4 in breezy-security.
- Ignore the problem completely, do nothing, and hope no-one notices.
- Try to form some kind of consortium with other distros to do
security support for some or all obsolete products
(perhaps just firefox 1.0.8, perhaps others too).
- Persuade Mozilla to change their mind about ending security
support for 1.0.8.
Most of these are unpalatable, very difficult, or both.
I think by far the most attractive is to backport 1.5.0.4. We know
that this can be done (early Dapper 1.5.0.4's were obviously
backports; I haven't checked backports.org but I don't see any
fundamental problems).
If we are careful with review of the _packaging_ arrangements as
opposed to the _code_ arrangements, we should be able to avoid too
much damage, and careful testing will help too. So I think we
should be able to provide a reasonable user experience.
This model could also be used well into the future, especially
considering the LTS requirement for Dapper. If we know in advance
that this is what our plan is, we can prepare, carefully test, and
then finally deploy a future Firefox 2.0 into dapper-updates and
dapper-security, before we are forced into the position of having to
delay while we think of a way to deal with a pressing security
problem.
Thanks for your attention.
Ian.
Posted Jun 7, 2006 20:35 UTC (Wed)
by nlee (guest, #730)
[Link] (23 responses)
Firefox is a pretty critical product, the rate of security releases is unlike to change. Dapper is likely to face the same issues once 2.0 is released. A better mechanism should be found.
Remove the system dependancies and ship Firefox as a portable app or as a klik. The extra cost of move additional bytes is less than the increased benefit from additional security.
Posted Jun 7, 2006 21:02 UTC (Wed)
by h2 (guest, #27965)
[Link]
I'm using debian, and was having too many glitches with firefox in kde on one of my installs, so I gave up on the deb packages, and just went with the firefox tarball package.
There have been zero dependency issues.
You can test this easily in ubuntu, just apt-get remove --purge firefox, then install the tarred firefox.
I'm also running the stock firefox debian deb package on other installs, those are fine too. As far as I know, at least in debian sid, which is what ubuntu is pulled from, firefox doesn't have major dependency issues, it's pretty much standalone. That might be wrong, I'm not 100% positive, since I'm not using ubuntu's restricted apt pool.
Posted Jun 7, 2006 21:10 UTC (Wed)
by madscientist (subscriber, #16861)
[Link] (20 responses)
Posted Jun 7, 2006 21:26 UTC (Wed)
by nlee (guest, #730)
[Link] (8 responses)
Regardless if the do decide to change policy on this one package, dependency are going to cause issues. There is a long list:
Posted Jun 7, 2006 21:38 UTC (Wed)
by madscientist (subscriber, #16861)
[Link] (7 responses)
Well, the extensions library is actually a good example of why they don't want to upgrade (if it's included in the package): anyone who's written any extensions to the 1.0.8 FireFox for Debian stable will surely be P.O.d if a "security update" installs a major version upgrade of FireFox which breaks all of her work that depends on the older version. It's exactly these sorts of situations that the stable policy Debian/Ubuntu have are designed to guard against. As for the prerequisites for the package, it's not a problem for a package to have a lot of prerequisites per se. It's only a problem if either of two things is true: (a) other packages depend on the to-be-replaced package, since that means they all must be upgraded as well. I don't think FF is in this category. Or (b), the new version of the to-be-replaced package requires some new support libraries or it won't work anymore, since that means you have to upgrade all those prerequisites first. I'm pretty sure even FF 1.5 will build OK with the versions currently in Debian Stable/Ubuntu Breezy. You won't have to upgrade all those packages (and everything they depend on, etc.)
Posted Jun 7, 2006 21:44 UTC (Wed)
by h2 (guest, #27965)
[Link] (3 responses)
The extension thing is another matter, but at some point you have to adapt yourself to that situation, every single new version, 1.5.3->1.5.4 for example, can break an extension, extension compatibility is tested every time you upgrade version no matter what.
Very few extension developers pay much attention to older versions, and it's up to them and only them to do that, there's no way anyone else could handle doing extension backward compatibility testing, that's not realistic, and won't happen. You're much better off using the latest firefox, with its glitches, especially if you use extensions heavily, but most people don't do that.
Posted Jun 9, 2006 12:40 UTC (Fri)
by louie (guest, #3285)
[Link] (2 responses)
hahahahaha. That's such a ... charmingly naive approach to QA. What about:
You have to test all of those too. And 'testing' something that depends on a browser is a hit or miss thing, given that a browser is so large.
All of the major distros are going to have to have a chat with moz.org at some point if they see themselves as seriously doing long-term desktop support, because it is clear that moz.org doesn't realize how deeply flawed their support policy is for those distros. Ubuntu is just the only one having this discussion in public right now.
Posted Jun 9, 2006 19:42 UTC (Fri)
by h2 (guest, #27965)
[Link] (1 responses)
If they don't want to pay for this, then their feelings on this question are fairly irrelevant. And what would that cost, tops? To maintain security patches for a handful of gecko based browsers? Probably one person could do it, so between redhat, suse, mandriva, etc, what are we talking about to get this desired security patch support? $10,000 a year? Maybe 20k if they hired two people?
This isn't very hard to do, if you need something done that nobody wants to do, pay someone to do it. And if you need it done, for reasons of corporate network stability, then pay for it. This isn't complicated.
If redhat/suse/mandriva can't afford to pay this pittance then they are in the wrong business and should contemplate entering into a new line of work, maybe ice cream sales or something.
Posted Jun 16, 2006 12:28 UTC (Fri)
by jzbiciak (guest, #5246)
[Link]
Posted Jun 7, 2006 21:51 UTC (Wed)
by nlee (guest, #730)
[Link] (2 responses)
It is a hard choice for Debian. The "unknown" security fixes in the latest and probably forth coming Firefox versions, make things very difficult. I guess this is one of the reasons I prefer Ubuntu for the desktop. They have a tight release cycle.
Posted Jun 7, 2006 21:55 UTC (Wed)
by h2 (guest, #27965)
[Link] (1 responses)
The same problems, by the way, exist for konqueror, kmail, to upgrade those you have to upgrade all of kde, so it's actually worse than firefox/tbird.
But significantly less people use those than firefox so it doesn't hit the news in this way.
Posted Jun 8, 2006 12:16 UTC (Thu)
by jond (subscriber, #37669)
[Link]
Posted Jun 7, 2006 21:31 UTC (Wed)
by h2 (guest, #27965)
[Link] (9 responses)
Yes, this is discussed frequently, it's a big problem for debian, firefox/mozilla just doesn't play well in this environment. Part of the problem is that the biggest firefox installed base is windows, and windows firefox uses autoupdate now, since 1.5. This makes sense in windows, since it's the only way to get users to actually apply security patches in a timely manner, but the model does not work for linux stable stuff, like debian, ubuntu, or whatever.
Since the risk of having an insecure browser, the number two access point for insecurities, email being number one, far outweighs any questions about not upgrading version in a stable pool, debian etc will have to bend on this one long term, since having users use unsafe browsers is just not a very good idea.
It's not as big a deal as they make it sound, it's just a browser, it's not like you are installing a new gnome or kde desktop, a new apache, or whatever. It's a standalone application more or less, like thunderbird.
It's unfortunate that mozilla foundation moved in this direction, but that's life, unless they decide to change that, it's unlikely to get resolved to anyone's satisfaction, I know it drives the debian security guys up the wall.
Posted Jun 7, 2006 21:58 UTC (Wed)
by jmorris42 (guest, #2203)
[Link] (8 responses)
Exactly. Mozilla.org has never really cared about the needs of the UNIX/Linux ports, only about Windows. This has only grown worse since they became attached to the cashflow from Google.
Generalizing your statement I'd say Mozilla products doesn't play well in enterprise environments period. Enterprise users value stability, reliability and long well established service cycles over new shiny features. Note that Debian and Ubuntu aren't alone in being abandoned by Mozilla.org. See the annoucement yesterday that RHEL3 is dumping Mozilla for Seamonkey for the same loss of upstream errata problems.
Personally I think dumping Firefox from any stable release is something to consider given their stated positions on errata. Too bad there isn't any viable replacements. There is a lesson here about over dependence on a single point of failure, especially one that makes no bones about our preferred platform being an afterthought. Suspect they would just drop the Linux & UNIX ports to shut us up is they didn't know it would just cause a fork, or worse, a whole new browser project.
Or perhaps the idea in the original post should be looked into, having the major distros share the burden of doing their own security patches has merit. This would probably require Mozilla.org to at least be willing to share details on the security issues though.
Posted Jun 7, 2006 22:25 UTC (Wed)
by h2 (guest, #27965)
[Link]
So I have to cut mozilla some slack in these areas.
The enterprise points are true, but will evolve over time I think, realistically, linux on the desktop is still at a very early phase in most parts of the world, despite many well publicized victories.
I know at least one major issue with 1.5 on linux came because the main developer worked on gnome, not kde. And it shows. Hopefully the portland stuff will standardize the external features like file dialogues etc to the desktop that is running it.
I also know that firefox and thunderbird made my switch from windows to linux much easier, since my most commonly used apps were there, with the same extensions and bookmarks etc, it wasn't nearly as big a jump as it would have been.
So it's improving.
Given the current cash flow of mozilla firefox, it might not be a bad idea to start putting some of those resources towards things like paying people do to really boring work like patching old versions. That's just not something most volunteers have any interest in doing.
Re the enterprise, also keep in mind, msie, while very well supported version to version over time, made massive jumps, from 3 to 4 to 5 to 5.5 to 6, in about 5 years. Each was a huge change, especially 4 and 6. It was only because MS believed that they had locked in the market that they stopped active development until competition from firefox forced them to reluctantly restart the ie team for ie 7. Which will also break a lot of compatibilities.
Given the speed of change of the web, and the fact that security vulnerabilities can and will be found, it might be that the stable distros and mozilla might need to bend a little bit towards each other.
Posted Jun 7, 2006 22:45 UTC (Wed)
by iabervon (subscriber, #722)
[Link] (1 responses)
Mozilla doesn't play well with system updates, but it's essentially to the point where it's not necessary for systems to deal with it at all, since users could just take care of it independantly.
Posted Jun 9, 2006 12:42 UTC (Fri)
by louie (guest, #3285)
[Link]
Posted Jun 8, 2006 1:25 UTC (Thu)
by ronaldcole (guest, #1462)
[Link] (3 responses)
Posted Jun 8, 2006 13:27 UTC (Thu)
by arcticwolf (guest, #8341)
[Link] (2 responses)
The whole *point* of these is that users (i.e., the companies using them, not the individual employees and end users) can be confident that things do not randomly change when they install updates for the distro.
Anyone who wants newer software versions can upgrade to a newer RHEL (or whatever); but those who'd rather stay with the versions they are already using and which they know work should not be forced to upgrade. New features and changes always have a chance to contain nasty surprises, and that's exactly what you don't want in these situations.
Posted Jun 8, 2006 18:57 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link] (1 responses)
I also wonder what about security holes in the version of Mozilla included in RHEL 2.1 (or is it actually Netscape 4? )
Posted Jun 9, 2006 17:34 UTC (Fri)
by djao (guest, #4263)
[Link]
You can sync to the DAG repository using your choice of apt, yum, up2date, or just use plain command line rpm.
A stable distribution using a backport policy gives you the option of remaining with the previous version. This does not in any way prevent you from upgrading to a new version yourself -- you have the option of doing either. By contrast, a distribution which tracks the upstream releases does not give you that option. Many people much prefer having the ability to choose. This is the main reason why backport policies are popular.
If you don't like having the option of going either way, you are always free to choose (!) a distribution like gentoo or fedora that tracks upstream releases closely.
Posted Jun 9, 2006 23:29 UTC (Fri)
by gerv (guest, #3376)
[Link]
That's demonstrably rubbish. Many of the developers use Linux, and it's a Tier 1 platform for us (along with Windows and Mac OS X) which gets full support and simultaneous release. And I don't see the supposed connection with Google which was implied by your cheap shot; perhaps you could elaborate?
> Mozilla products doesn't play well in enterprise environments period
That's not surprising; Firefox is not after the enterprise market. If enterprise distro makers want to use our codebase to make something for the enterprise, they can, but they may need to spend those lovely enterprise subscription fees on doing some work on it.
> See the annoucement yesterday that RHEL3 is dumping Mozilla for Seamonkey
This seems entirely reasonable to me. Mozilla is an end-of-lifed product; Seamonkey is the community continuation. Props to the Seamonkey folks for doing a professional enough job that RHEL have come knocking.
> This would probably require Mozilla.org to at least be willing to share
There are many distribution representatives on our security email lists, including people from Debian (don't know about Ubuntu off the top of my head, but I'd be surprised if they weren't). Applicants from other distros should contact Dan Veditz.
Gerv
Posted Jun 9, 2006 7:06 UTC (Fri)
by petegn (guest, #847)
[Link]
Run with the problem version or use a new version i can not see any great problem with that .
Stick with the systems ideals stick with the problem step outside the systems ideals solve the problem simply .
Pete .
Posted Jun 14, 2006 16:47 UTC (Wed)
by mdz@debian.org (guest, #14112)
[Link]
Posted Jun 7, 2006 21:05 UTC (Wed)
by mlinksva (guest, #38268)
[Link] (12 responses)
I love love to see FF 2.0 backported (officially supported) to 6.06 as soon as the former is released.
Posted Jun 7, 2006 21:13 UTC (Wed)
by corbet (editor, #1)
[Link]
Posted Jun 7, 2006 21:13 UTC (Wed)
by tjc (guest, #137)
[Link]
Posted Jun 7, 2006 21:21 UTC (Wed)
by h2 (guest, #27965)
[Link] (9 responses)
There are other fixes that avoid firefox 1.5 eating up a huge chunk of your available ram, none of which should have been necessary, and none of which are applicable without doing manual about:config changes.
The gnome simple user interface coupled with limited gui user configuration options coupled with highly questionable default option choices disease seems to have crept into 1.5 to an unfortunate degree.
While I have used mozilla/phoenix/firebird/firefox since each version has come out as my default, the 1.5 had by far the most serious issues, and the worst default options, it's not uncommon to read reports of 1.5 munching upto 1/2 a gig of ram for example, that's simply absurd.
The way firefox tried to speed up page loads and history back was truly sad, when you compare it to say opera, it was just something that should not have been allowed out.
Still use firefox on linux as my default, but it was only because Konqueror did not have the same extension capability, it wasn't for firefox itself, I'd much rather use konqueror on linux if I could have the same extensions, but the extensions save firefox in this case.
Posted Jun 7, 2006 21:40 UTC (Wed)
by cventers (guest, #31465)
[Link] (2 responses)
I could swear that Konqueror history sped up in 3.5.3, but maybe it was
One of the nice things about the KDE4/Qt4 efforts is that we're likely to
Posted Jun 7, 2006 21:50 UTC (Wed)
by h2 (guest, #27965)
[Link] (1 responses)
Konqueror really benefited from the applewebkit upgrades of safari in khtml, no doubt about that, it's very solid now.
I don't know where you got that idea about firefox vs MSIE, that's just some MS spin you fell for, firefox does not have active x, which is a core access to the OS. Firefox will never have that, so firefox will never have that deep level vulnerability. Firefox has vulnerabilities, and if you read them carefully, most are not very serious, not like somebody tricking active x to install a rootkit into windows. No firefox user I have switched from MSIE has experienced ANY spyware infections. All MSIE users have these, no matter what MS does to try to stop it. XP SP 2 did not succeed in securing it, nothing MS has done has succeeded, because MSIE is insecure by design, it can never resolve that issue as long as active x exists.
Posted Jun 8, 2006 10:44 UTC (Thu)
by nix (subscriber, #2304)
[Link]
It wouldn't be too terribly difficult to write a scripting language KPart, but there are security concerns: Konqueror can do anything KDE can do...
Posted Jun 7, 2006 21:50 UTC (Wed)
by tjc (guest, #137)
[Link] (4 responses)
Posted Jun 7, 2006 21:56 UTC (Wed)
by corbet (editor, #1)
[Link] (3 responses)
Crashes are a pain, though; Firefox has seemed a bit wobbly for a while now.
Posted Jun 8, 2006 2:11 UTC (Thu)
by Mithrandir (guest, #3031)
[Link]
Firefox still won't be completely stable, but it helps.
Posted Jun 8, 2006 12:20 UTC (Thu)
by jond (subscriber, #37669)
[Link]
Posted Jun 8, 2006 14:15 UTC (Thu)
by tjc (guest, #137)
[Link]
I have configured the search bar to use "/", but "n" doesn't work (and I find "F3" to be very Windows-like), and it seems to have focus problems which I have not been able to pin down. Sometimes I press "/" and start typing, the search bar doesn't pop, and the text goes to /dev/null, or some other useless place. I have to grab the mouse and click on the client area, and start over. I'm wondering if this is somehow related to using "focus follows pointer" on my window manager...
Posted Jun 8, 2006 9:18 UTC (Thu)
by jschrod (subscriber, #1646)
[Link]
Cheers, Joachim
Posted Jun 7, 2006 21:48 UTC (Wed)
by lacostej (guest, #2760)
[Link] (2 responses)
Posted Jun 7, 2006 23:00 UTC (Wed)
by man_ls (guest, #15091)
[Link] (1 responses)
Posted Jun 9, 2006 5:12 UTC (Fri)
by lacostej (guest, #2760)
[Link]
Or when an application changes a lot, it becomes very very hard to backport every fix to various stable releases.
Mozilla decides to stop supporting old releases, in part because they don't have the man power to do that. I guess they would do it if they were paid to.
When Microsoft fixes a vulnerability for a package, they have to create and test the fix for various stable versions. Sometimes this applications have been used as basis for third party, so Microsoft doesn't even fully control the applications. Hence, sometimes, the time it takes to solve the problem.
Posted Jun 7, 2006 22:55 UTC (Wed)
by barryn (subscriber, #5996)
[Link]
RHEL 2.1 shipped with Mozilla 1.0.1. It was updated to 1.0.2, then 1.4.x, then 1.7.xx. It's currently at 1.7.13. RHEL 3 and 4 started with newer Mozilla releases, but they have also been upgraded likewise.
The Red Hat policy AFAIK is to avoid upgrading to newer upstream versions whenever possible, so I guess Red Hat *really* found it way too hard to keep backporting Mozilla fixes.
It will be interesting to see what Red Hat does with Firefox in RHEL 4; that is currently at 1.0.8, like Ubuntu Breezy.
Posted Jun 8, 2006 3:04 UTC (Thu)
by Richard_J_Neill (subscriber, #23093)
[Link] (3 responses)
Each extension should be in a RPM (or deb), located in a central repository, and, installed system wide, and updated by the distro. In this case, the issue would vanish.
Posted Jun 9, 2006 2:20 UTC (Fri)
by jamesh (guest, #1159)
[Link] (1 responses)
Posted Sep 25, 2006 18:20 UTC (Mon)
by cortana (subscriber, #24596)
[Link]
Posted Jun 9, 2006 23:31 UTC (Fri)
by gerv (guest, #3376)
[Link]
If your distro hasn't packaged the hundreds of extensions on addons.mozilla.org this way, complain to them :-)
Gerv
Posted Jun 8, 2006 11:01 UTC (Thu)
by jpetso (subscriber, #36230)
[Link] (1 responses)
It's a shame that those distros don't even update minor versions
Security updates for multiple years may be a good idea for server
This is my only major gripe against binary distros like (K)Ubuntu. I mean
Posted Jun 8, 2006 12:51 UTC (Thu)
by tao (subscriber, #17563)
[Link]
Maybe if you had to work on a distribution with 15000 packages and try to keep them all in sync, you'd understand the necessity of avoiding major changes in stable releases...
Posted Jun 8, 2006 15:10 UTC (Thu)
by tseaver (guest, #1544)
[Link] (2 responses)
Who today could rely on only what was in Netscape 4, for instance,
Ubunut *does* bundle many of the "major" extensions as .deb files,
Ergo, +1 for backporting 1.5.0.4 to Breezy.
Posted Jun 8, 2006 19:55 UTC (Thu)
by ncm (guest, #165)
[Link]
If a later version is incompatible with extensions meant for the older, it means they need to make the version number part of the package name. This is totally familiar usage as applied to libraries, and most Debian installations have several versions of many libraries installed.
The problem is that the older versions will be increasingly buggy and increasingly insecure. For many uses -- particularly corporate uses -- these don't matter at all. However, there should be a way to default to keeping the older versions from trying to connect outside the local domain; the proxy configuration might serve. Also, it should be possible to run both the old version and the new version simultaneously.
Posted Jun 16, 2006 15:23 UTC (Fri)
by jzbiciak (guest, #5246)
[Link]
I think it was around 2002 we finally started officially supporting Mozilla for internal web applications in a limited capacity.
Maybe they should distribute it as a portable app version instead.Move to a portable app model
I'm running the portable linux firefox, in kde, just download the tar gzipped file, extract to location, and that's about it. I guess I could test it on an older install, but I think there is no real dependency issue, nothing is indicated on the mozilla.com site about that for linux installs.Move to a portable app model
I don't think the concern with backporting FireFox really revolves around system dependencies. I think mainly it's because the model for stable releases in Ubuntu and Debian has always been to never upgrade to newer versions, but ONLY to backport fixes to existing versions. The very definition of "stable" to those distributions means no new major versions. It would be a major break in policy for them.
Move to a portable app model
Maybe that is true. Firefox might be a special case however. For example is the Debian project willing to maintain the Firefox extensions library as well? Extensions also provide a vector for security, none of the new extensions work with 1.0.4Move to a portable app model
http://packages.debian.org/stable/web/mozilla-firefox
http://packages.debian.org/unstable/web/firefox
Move to a portable app model
Easy enough to test, install tarred firefox 1.5 on debian stable, if it runs fine, that's the answer. I might try that in the next few days to see, I've been wanting to do a debian stable or etch install anyway, might as well do both and see how that stuff works. My guess is firefox will install fine as a tarred thing, maybe not the deb, but that's easy to see too by a simple apt-get install firefox -s test.Move to a portable app model
"Easy enough to test, install tarred firefox 1.5 on debian stable, if it runs fine, that's the answer."Move to a portable app model
* the universe of plugins?
* epiphany/galeon?
* yelp?
* anything based on the Java SWT?
so how much are those distros contributing to mozilla to get that long term support? With the exception of debian, we are after all talking about for profit corporations here. So if they want that type of support, I suggest they get together and create a few staff positions at mozilla.com whose sole role is maintaining old mozilla/firefox versions.Move to a portable app model
Actually, as I see it, since the Mozilla folks get $$ every time someone searches at Google w/ their browser, I'd say the fact that distros choose to make Firefox their default browser is payment enough.Move to a portable app model
You make a very valid point. One response might be, how do we know any backport feature don't break the current set of firefox extensions in the debian archive? Move to a portable app model
Not to sidetrack, but this is why I prefer kanotix, it's a direct access to sid, usually not much more than a week goes by before I have the latest tbird or firefox, but at the cost of being in an unstable pool. And it's unstable, no doubt.Move to a portable app model
The issue here is it now being impossible to separate out changes made upstream that are security fixes and those that aren't. afaik, the problem isn't the same for KDE, because they have a security policy more in-line with Debian's.Move to a portable app model
"I think mainly it's because the model for stable releases in Ubuntu and Debian has always been to never upgrade to newer versions, but ONLY to backport fixes to existing versions."Move to a portable app model
> Yes, this is discussed frequently, it's a big problem for debian,Root of the problem is Mozilla.org is Windows centric
> firefox/mozilla just doesn't play well in this environment. Part of the
> problem is that the biggest firefox installed base is windows,
While not disagreeing with your points, it's also important to keep in mind that firefox basically singlehandedly kept the internet free. MS was VERY close to forcing us into an active x powered web, with MS created standards, vbscript, you name it. We went from there to the new msn search site being done in xhtml 1.0 strict, quite a leap in my opinion.Root of the problem is Mozilla.org is Windows centric
To be fair, the autoupdate of firefox actually works amazingly well on Linux. I'm running a copy of firefox that I downloaded and untarred in a random subdirectory of my home directory, and symlinked into ~/bin, and it's autoupdated (when I decided to take the update) multiple times, having detected by itself that a new version is available. I don't think I've seen any other software for any operating system that's been able to upgrade itself without being installed.Root of the problem is Mozilla.org is Windows centric
This would all be well and good *if nothing depended on firefox*. But from day one firefox has also been sold as a platform for people to develop on. And that will never happen in any large-scale way with their cavalier attitude towards API/ABI compatibility and upgrades.Root of the problem is Mozilla.org is Windows centric
RHEL3 should also either upgrade or dump their ancient and practically unusable SpamAssassin for the same reasons. Enterprise distros didn't seem to forsee the very real consequence of bitrot in their distros due to their "backport only" policies.Root of the problem is Mozilla.org is Windows centric
You don't seem to understand the purpose of enterprise distributions.Root of the problem is Mozilla.org is Windows centric
However an ancient SpamAssassin is much less effective at killling spam. Upstream keeps changing the format of the database, so you can't use a recent rules set with an old SpamAssassin. Many spammers have already adapted to that old version.Root of the problem is Mozilla.org is Windows centric
Nothing in the world is preventing you from upgrading to the DAG repository's spamassassin-3.1.2-1.el3.rf.i386.rpm, which, although distributed by a third party, is specifically designed to be compatible with RHEL3.
Root of the problem is Mozilla.org is Windows centric
> Exactly. Mozilla.org has never really cared about the needs of the Root of the problem is Mozilla.org is Windows centric
> UNIX/Linux ports, only about Windows.
> for the same loss of upstream errata problems.
> details on the security issues though.
well they got 2 choices .. Move to a portable app model
There are a number of reasons why that approach wouldn't work for Ubuntu, but they aren't relevant since it wouldn't solve the problem anyway. We can move to new upstream versions without resorting to using precompiled binaries; the issue is that this introduces new bugs, unexpectedly changes behaviour, and breaks configuration changes (such as extensions) for users who are using an otherwise stable product.Move to a portable app model
I don't see any downsides to backporting 1.5.0.4. Did I miss what looks "not particulary good" for that option?The problem of Firefox in Ubuntu Breezy
It's a major change in what's supposed to be a stable distribution. For most people, the biggest obnoxiousness will be the fact that all extensions break and have to be updated.
The problem of Firefox in Ubuntu Breezy
The problem of Firefox in Ubuntu Breezy
I don't see any downsides to backporting 1.5.0.4.
Well, 1.5.x seems to be less stable than 1.0.x, at least on Solaris. There are a few cases where bad HTML will crash the browser. I haven't tried 1.5.x on Linux yet, but hopefully it's better.
downsides are absolutely horrible memory handling, on each new firefox install I have to go in manually and set about:config to only store a cached version of the last page or two. Also turning off prefetch, which is another really bad thing to have as default, it causes all kinds of little problems. That should not have been a default setting.The problem of Firefox in Ubuntu Breezy
I feel you. But I do great without extensions, so I use Konqueror The problem of Firefox in Ubuntu Breezy
exclusively.
just subliminal. In any case, Konqueror's history has always been
_faster_ for me than Firefox's (as well as Konqueror's rendering and
startup), so Firefox eating boatloads more memory seems silly (not to
mention the disturbing appearance that all the early claims of Firefox
being more secure than Internet Explorer appear, to my eyes anyway,
completely false).
see apps like Konqueror ported over to Windows. I don't personally care
since I don't use the proprietary OS, but having an open source browser
as awesome as Konq available on Windows means more mainstream competition
for Firefox, which will hopefully force them to get their act together.
I use a lot of extensions, i depend on them for development, konqueror as a base is better I think than firefox as a base, but the extensions just can't be matched, that's because konqueror extensions have to be done in c or c++, can't remember which, they don't have an extension scripting language like firefox has. Currently only adblock is ported. Which is great, but it's not good enough, sadly.The problem of Firefox in Ubuntu Breezy
Konqueror extensions (KParts) are C++ (although of course you can write most of them in any language GCC can handle and specifically any language there are KParts bindings for).The problem of Firefox in Ubuntu Breezy
In some ways version 0.9.3 was the high-water mark for Firefox (except for the security issues, of course). IIRC that was last release without that damnable search bar on the bottom of the window, and it didn't seem to crash too much.The problem of Firefox in Ubuntu Breezy
Hey, I like the search bar at the bottom! I can finally search for stuff without the dialog blocking what I was trying to find...
Search bar
Most of the destabilisation I've noticed seems to be related to upgrades not playing so nicely with your old profile. If you're seeing a lot of crashes often you can improve things by moving away your old profile directory (in .mozilla/firefox on my box), then opening firefox to create a new profile, then copying back the important stuff from your old profile.Search bar
Agreed regarding the search bar. Also, because the pop-up was specified in a particular fashion (some kind-of window ownership relation I forget the details of) with something like the ion window manager it was impossible to move the pop-up window out of the way of whatever it was obscuring.Search bar
Search bar
Hey, I like the search bar at the bottom!
I had 0.9.3 configured to use vi keystrokes, so I could search with "/" and "n" without the dialog window getting in the way.
How about using SeaMonkey? It's what I do, because the Firefox developers obviously target a user group where I'm not in. One can always just install the Browser component, if one wants a smaller installation.The problem of Firefox in Ubuntu Breezy
I think that now people will understand why it sometimes takes time for Microsoft to get a patch out.The problem of Firefox in Ubuntu Breezy
I don't. Why? They publish the OS and the applications, so I don't see how it relates to the original posting.
The problem of Firefox in Ubuntu Breezy
The idea behing stable it to only publish security fixes (or extremely important new features).The problem of Firefox in Ubuntu Breezy
Red Hat has been dealing with this conundrum longer, in the form of RHEL and Mozilla. It may be instructive to look at their history in this regard.Look at Red Hat, RHEL, and Mozilla...
The real problem is that firefox uses a stupid extension model. There are some terrific firefox extensions available. However, I want to use my package manager to control them! Firefox extensions RPMS
... so package the extensions as RPMs or DEBs. If you unzip an extension and place its contents in the right place (/usr/lib/firefox/extensions/$extension-uuid, iirc), firefox will pick it up next time it starts up. Sounds pretty easy to package to me.Firefox extensions RPMS
Yeah, since 1.5 the system has been sane as you describe. In 1.0 and earlier, however, it was much nastier.Firefox extensions RPMS
The model you propose is entirely possible; put an extension in the right place using your RPM or DEB, and Firefox will notice and initialise it.Firefox extensions RPMS
This issue shows again how broken that whole "freeze the versions" The problem of Firefox in Ubuntu Breezy
concept actually is.
(x.y.1 -> x.y.2) and instead patch everything themselves. I'm actually
surprised that this problem has been able to be ignored for so long, but
sooner or later it has to come up. You can't seriously maintain security
updates for longer than the mainline applications do, and then you're
supposed to upgrade to the next major version, because the previous one
is outdated, unmaintained and plain obsolete anyways.
software and the base system, but it's not viable for desktop
applications. IMHO the users should just bite the bullet and cope with
the implications of a major upgrade. It should not be up to the distro to
maintain what is no longer maintained.
hey, Gentoo can also provide a stable branch while continuously updating
their software, why can't any of the binary distros do something similar?
Damn those stability gurus.
Well, if x.y.1 -> x.y.2 actually is a minor update that only fixes security problems (or horrible crashes, dataloss, etc), then we *do* accept new minor versions. The problem with Firefox, the Linux kernel, etc, is that the diff from x.y.1 to x.y.2 is BIG, and involves a lot more things than just fixes for bugs.The problem of Firefox in Ubuntu Breezy
One issue even for the "enterprise" case (and particularly givenThe problem of Firefox in Ubuntu Breezy
Dapper's 5 year support commitment) is that the browser itself
is a *platform* for other enterprise applications; the typical
"version freeze" / stability requirement is in very sharp tension
with those applications' needs.
which was the "stable" browser 5 years ago? As a Breezy user, I was
running an on-the-side Firefox 1.5 version, for instance, because I
needed support for newer Web standards, etc. not present in 1.0.8.
which presumably means that the decision to backport the browser
would include backporting the packaged extensions. Users with non-packaged
extensions in their profiles will get those extensions disabled,
typically, until a compatible upgrade is found.
Agreed.Backporting
Actually, interestingly, we hung onto Netscape 4.7 at work for a very, very long time. Long after Mozilla 1.0 released. Considering that 4.6 and 4.7 were just bugfix releases on 4.5, and 4.5 came out in 1998, that's a pretty long window, and I'd guess pretty typical of corporate environments.The problem of Firefox in Ubuntu Breezy