Firefox 1.0.2 or 1.0.4?! Problems with extensions

[Ante Karamatić]

Mozilla released 1.0.4 firefox, and ubuntu backported fixes to 1.0.2. But,
mozilla doesn't allow instaling extensions from their site on firefox <1.0.4.
Since ubuntu's mozilla has 1.0.3 and 1.0.4 fixes, it acctually, is 1.0.4
firefox. But, version string in programs says 1.0.2.

This is very, hm...., stoopid (?!) situation couse Ubuntu's firefox IS 1.0.4,
but reports as 1.0.2. But, if version strings remains 1.0.2, users will not be
able to download/install any exntesions.

[Daniel Robitaille (robitaille)]

I can confirm this bug. It seems that unless your firefox display am internal
version string of 1.0.4 or better (which isn't the case for any Ubuntu version
of firefox), if you click on "get more extensions", or "get more themes" from
their respectives menus in "tools", you get automatically redirected to:

   http://www.mozilla.org/products/firefox/upgrade/

without a way to actually get to the mozilla.org's download pages for extensions
or themes.

[Magnus Therning (magnus)]

Just in case someone thought circumventing this would be as easy as changing
app.version in about:config, think again. It seems the Mozilla feature is a bit
cleverer than that.

It also doesn't work to copy-paste the extensions URL from a FireFox 1.0.4
running on Windows
(https://addons.mozilla.org/extensions/?application={ec8030f7-c20a-464f-9b0e-13a3a9e97384}).
(I haven't tried copy-pasting from a FireFox 1.0.4 running on Linux though.)

IMHO this is an important usability issue. It also isn't a one-time thing, it is
bound to happen again in the future.

[Michael R. Head (burner)]

Setting general.useragent.vendorSub to 1.0.4 in about:config seems to let me
access addons.mozilla.org

mike

[Ante Karamatić (ivoks)]

(In reply to comment #3)
> Setting general.useragent.vendorSub to 1.0.4 in about:config seems to let me
> access addons.mozilla.org

That's right. Maybe new releases should have vendorSub changed?

[Corey Burger (corey.burger)]

*** Bug 17091 has been marked as a duplicate of this bug. ***

[Thom May (thombot)]

*** Bug 17153 has been marked as a duplicate of this bug. ***

[Johnathan (jconley)]

I'm sure you had a reason for backporting to 1.0.2, but IMO the web browser is
the most important user app, so it should be kept up to date with as little
abiguity as possible.
1.0.3 has been out for a long time... There shouldn't be so many changes that
prohibit an upgrade.
And as is evidenced here, the extentions/scripting community is a huge driving
factor in the minor non-security updates included in security-fix releases.
Applying security-only patches just isn't going to keep the users happy + other
distros seem to keep up with Firefox fine.

[Daniel Robitaille (robitaille)]

*** Bug 17317 has been marked as a duplicate of this bug. ***

[great snoopy (great-snoopy)]

(In reply to comment #7)

> 1.0.3 has been out for a long time... There shouldn't be so many changes that
> prohibit an upgrade.

Applying security patches only is a very good thing in order to preserve
compatibility with
other modules of the distribution. Until hoary's end of life major other updates
to firefox
will occur, even the release of a new major version that could more probabbly
disrupt some things in the distro.
I rather find Mozilla's atitude of denying access to older clients PLAIN STUPID,
once for such an enforcement itself and twice because the site can recognize the
ubuntu specific
build, and could just make an exception for that browser or other browsers with
backported
patches.

I really hope that the Ubuntu developers will actually keep this practice of
backporting
sec. patches only.
Eventually I could propose that the Ubuntu packages to have an extra patch that
sets the default of general.useragent.vendorSub to the current security patch,
for example :

The actual ubuntu build has all the security patches included in firefox 1.0.4
but not
the other (eventual )features of 1.0.4. The default general.useragent.vendorSub
should
be 1.0.4. Even if firefox reaches a new major version like 1.1.0, while ubuntu's
build
is only 1.0.2, the vendorsub should be raised to 1.1.0 by default as long as all
the security patches incorporated in 1.1.0 are also incorporated in ubuntu's 1.0.2

HOWEVER, I still find Mozilla's atitude wrong and I still think it's THEM who should
not place such stupid enforcements. Backporting sec patches only is a very good
measure
to keep compatibility along one distribution,and nobody shoud force the user to
install
a particular other version. If this case is a simple one, but what about if we
would be
dealing with a library like mysql client libs or qt, or gnome/gtk libs - things
that could disrupt a whole bunch of stuff if upgraded. I have seen this a lot of
times.

[David D Miller (justdave)]

(In reply to comment #9)
> I rather find Mozilla's atitude of denying access to older clients
> PLAIN STUPID, once for such an enforcement itself and twice because
> the site can recognize the ubuntu specific build, and could just
> make an exception for that browser or other browsers with backported
> patches.

This deserves some explanation, since I'm the person who set that up. We have
never blocked old versions from the addons site before. We have no choice this
time. The severity of the security vulnerability in question demands it. If
you can get content from a site in Firefox's extension install whitelist loaded
in an IFRAME, you can execute arbitrary code on the user's computer. That's
serious. It would be irresponsible of us NOT to block vulnerable clients from
getting content from that site, since it's included in the default whitelist
that ships with Firefox.

I'm perfectly willing to make an exception for Ubuntu, however, the UserAgent
string in the Ubuntu Firefox doesn't appear to have changed when the security
patches were applied, so we have no way to tell whether the Ubuntu package
you're running has the fix or not. Yes, the UserAgent is a stupid way to check
versions, but it's the only option we have without actually delivering content
to the browser to run a script, which would allow the exploit to work still.
Typically, people who mess with their useragent are better at keeping up with
security updates, or that's the hope anyway.

[David D Miller (justdave)]

*** Bug 17277 has been marked as a duplicate of this bug. ***

[Matthew East (mdke)]

> I'm perfectly willing to make an exception for Ubuntu

Presumably the exception will have to be made for other distributions as well,
because as i understand it the standard method of doing security upgrades is by
patching the released version to close the security hole. Its not just us ;)

M

[great snoopy (great-snoopy)]

Hi Dave,
* True, the bug is really ugly, but I think a solution should be found to
this issue.Also I admit that your intentions were more than positive
I also think a solution to issues like this should be found. It is
unfortunate that Firefox is the first victim of such problems, but
many more other projects could be affected by the difference between
the software version itself and the security patch level of that software.
For example a lot of security scanners detect certain versions of
ssh servers or web servers as vulnerable to various attacks even if
the security patches are always backported by the distro vendor
(be it redhat,novell/suse, debian, ubuntu or others).Some
people ran into problems with their employers when some smartass
third party security auditor reported that company X's IT
infrastructure is vulnerable to ceratin attacks, even if in reality
al the patches were there and nothing was really vulnerable.

The best solution would be I think to find a way to easily
discern betwen a product's version (let's name this features version)
and the security version, or patch level. In the case of
firefox this patch level could be automatically retrieved
by the user agent or by some ffox specific java script code.

But I think you agree with me that a mechanism
should be implemented, so that you on your side can block
vulnerable clients AND also packagers can mantain their
internal versioning and backporting scheme.
And again, I agree with you about your motivations,
but it's quite stupid when other ..."innocent" :) clients
are blocked to access a certain resource based on version only.

I had 2 proposals, one regarding applying a patch by the
ubuntu team to set the useragent default for their package
and this one, more generic to keep a supplementary patchlevel
for every product.(Some vendors in fact do this,even if
sometimes their scheme of appending an extra number to the
vanilla version messes other things -see for ex redhat kernels;
A more elegant sollution should be found)

Who knows, other solutions could exist; I think it's the
public and/or the developers and/or the packagers/vendors
that should also think about this problem and find
a reasonable solution.

Best regards,

[Thom May (thombot)]

We're talking with upstream to get a reasonable solution implemented for both sides.

[Michael R. Head (burner)]

Some people have been asking me via email about what 'about:config' is due to
the workaround I mentioned in comment #3, so I'm just going to explain it here.

It's just a psuedo-URL that you can type into your firefox location bar to
access special configuration options, such as general.useragent.vendorSub.

When I said,
"Setting general.useragent.vendorSub to 1.0.4 in about:config seems to let me
access addons.mozilla.org,"
I meant that I typed 'about:config' into my location bar, typed
'general.useragent.vendorSub' into the search bar that appears on the page,
double clicked it, and entered 1.0.4.

hope this helps those in need,
mike

[Tim LePes (tlepes)]

(In reply to comment #13)

Great Snoopy, I think you make an excellent suggestion. Firefox could keep a
core (feature-set/api) version number and a second patch/security level version
number. If there is not already a suggestion like this on Mozilla's bugzilla
for Firefox, I think I will add it myself.

I understand that Mozilla has good reasons for stopping people from going
directly into the extensions/updates section. But perhaps it would have been a
little smoother if they had put a link on that warning page that would forward
you through, having been so warned. The brick-wall approach is a little harsh.

I believe that there is a larger issue with Firefox and extensions, which I
guess I'll have to post to Mozilla. Even so I'll vent here anyway: Every time
there is a minor upgrade to Firefox, it seems, all the extension break and you
have to either wait for updated packages or go manually download the XPI files
and bump version numbers to re-install them. This is kludgy. And even more so
it is becoming a major pain for users. A hassle for those of us who know how to
circumvent the problem, and a stumbling block and source of intense frustration
for those who are not so savvy. I don't know about you, but for me some of the
extensions are very important.

I have noticed that in the RDF files of many extensions, you started to see a
plus "+" character tacked on to the max version number. But apparently Firefox
is ignoring this and disabling extension anyway. Now I have never written an
extension to Firefox so I don't know the mechanics. But if there is an API or
base feature set, maybe they can keep a separate version for the extensions API
so they don't break every minor update. Or, perhaps, they need to come up with
better policy on min/max versioning and communicate that to the extensions
developers so that things work better. Why does everything break on a
3rd-decimal version change? (1.0.x to 1.0.y)??? Why not make it easier and
have them track the second decimal version? If there are changes in a 3rd-place
version update that will break extensions (api or feature set change, whatever),
then you can make it policy that it should be a 2nd-decimal upgrade (1.0.x to
1.1.0). SOMETHING. Any ideas here from knowledgeable parties would be grand.
As it stands, the logistics of having umpteen extension authors have to scramble
to repackage (and they don't scramble as far as I can tell) just plain sucks.

Okay... end rant. Time to hit Mozilla's forums and bugtracker. Peace!

Tim

[Tim LePes (tlepes)]

I went ahead and added bug numbers 295889 and 295893 to Mozilla's Bugzilla for
Firefox, as noted in my earlier comments...

You can find them on https://bugzilla.mozilla.org/

295889 - Too many extensions (and themes) break on minor upgrades ...
298893 - Suggestion for Security Patch Level version be mainained ...

Peace!

[Mike Connor (mconnor)]

I don't suppose there's a list of what patches from 1.0.3/1.0.4 _didn't_ get
taken for Ubuntu's updated 1.0.2 package?

1.0.x is a stable branch at this point, with only security fixes/fixes for
branch regressions caused by previous branch security fixes being approved. So
I'm curious as to what people think will break, and why changing the browser
version would break the distro. I do want to minimize pain for the various
distros, so if patches are going on "stable" branches that cause problems, I/we
need to know.

[Billy Pilgrim (bpilgrim1979)]

This situation just going to cause massive confusion for end users of Ubuntu and
Firefox with every update. Please figure out a solution. :) When I currently
view Help > About Mozilla Firefox and see 1.0.2, I ask myself why does Ubuntu
have an out of date version?? The apt-get update method should be *better* than
Windows .exe update installs, not more confusing!

[Matthew East (mdke)]

(In reply to comment #19)
> This situation just going to cause massive confusion for end users of Ubuntu and
> Firefox with every update. Please figure out a solution. :) When I currently
> view Help > About Mozilla Firefox and see 1.0.2, I ask myself why does Ubuntu
> have an out of date version?? The apt-get update method should be *better* than
> Windows .exe update installs, not more confusing!

As I understand it, all linux distributions do security patches in this way.
Security fixes are backported like that.

So, when Ubuntu is released, until the next release, yes the packages will be
"out of date". That is the price of having a nice stable distribution which is
tested in a 6 month release cycle.

M

[Mélodie (meets)]

(In reply to comment #20)
> (In reply to comment #19)
> > This situation just going to cause massive confusion for end users of Ubuntu and
> > Firefox with every update.
...
> That is the price of having a nice stable distribution which is
> tested in a 6 month release cycle.
Hello,
I am an end user. I just tried 'about:config' and so on. When I was on the point
of downloading
a pair of new extensions (I did install some, as Adblock... under other
distributions preceedingly)
I saw once more this message that say 'this extension is not signed' or so.

1st point: I've got a nice stable distribution, Ubuntu Hoary.

2nd point: we've got apt-authentication for secure dowloads.

3rd point: once, I dowloaded an external update of Enigmail from within
the Mozilla-Thunderbird-Enigmail interface.
As a result, the mail client started crashing each time I was selecting a mail,
and I had to suppress the new extention by hand, rename the folder as the defaut
folder name contains deux words with a space :(
and dl it again with apt-get.

Just to say any update that comes (as user) out of the distribution will not get
the distro to crash, but the application possibly.

Then, I'ts regretable to have security fixes (Firefox) but no garantee on Firefox
extentions that are not signed.

My wish, as an end user as well as a newbie, would be that the Ubuntu developpers
do package a handful of extensions within the distribution, for exemple as optional
packages. This way, it would be on the continuing line of a completely integrated
distribution, and leave the freedom to more 'risked' users to install the newest
versions to compile if they like to, get extensions not signed if they wish, not as
an obligation... (I decided for this time, not to install the unsigned extensions)
Best greetings, Mélodie.

[Mike Connor (mconnor)]

The issue that's not resolved and seems to not warrant a response, is the
difference between the set of security fixes backported to 1.0.2 and the set of
security fixes that differs mozilla.org's 1.0.2 and 1.0.4. We're not changing
features/APIs/other things, other than to eliminate unsafe bits that extensions
may use (the core browser should not exhibit any behavioural or functionality
changes on the 1.0.x branch).

[VictorArguelles (v-arguelles)]

(In reply to comment #10)

> I'm perfectly willing to make an exception for Ubuntu, however, the UserAgent
> string in the Ubuntu Firefox doesn't appear to have changed when the security
> patches were applied, so we have no way to tell whether the Ubuntu package
> you're running has the fix or not.

general.useragent.vendorComment
has the value
Ubuntu package 1.0.4~5.04ubp1+1.0.2

Is there a way for you to check for that value? It seems to be a way around it.

[Vali Dragnuta (vali-dragnuta-asf)]

> So, when Ubuntu is released, until the next release, yes the packages will be
> "out of date". That is the price of having a nice stable distribution which is
> tested in a 6 month release cycle.

Besides that, mozilla is only a special case. Very little things rely on mozilla.
But let's asume it's not mozilla, it's the kernel or glibc. Well, between
two consecutive versions of the kernel and/or glibc there are a lot of changes
with some features added, some disabled, OR some tings re-implemented in order
to fix some bug. The problem is that any change in the kernel's api, or in
glibc could easily trigger bad things in anything that uses that package. Virtually
everything depends on glibc for example. And when such package is changed,
sometimes in certain particular scenario a function's result differs and
an application crashes. This is exactly the kind of things that are TESTED and
RETESTED during the 6 months or 1 year development cycle of a distro.
Suppose the following scenario :
You have a hosting company.
Your clients often use SSL for their web applications.
A bug in openssl version N is descovered. Meanwhile
openssl N+1 appeared, but with this appearance some
cipher was obsoleted and eventually eliminated.
If you upgrade openssl to N+1 on your machines,
you could end with apache not not being able to
load openssl version N (because that's the version
it was compile with) OR not being able to use the
obsoleted cipher in openssl.
Your clients will be mad and you will lose a lot of money.
As a distro vendor you have two options : to trust
the developers (which you CANNOT control)
of a certain application or library that
they will not introduce dramatic changes
between minor versions of their software and
break your distribution
OR
take a proactive atitude on your own and
use the same version of the library, with
just the security patches installed by your
OWN developers/maintainers which you CAN
control.
You see, some distributions care a lot about
their stability. Debian is proud to certify
you that when they release a new distro version
it just works, and they will make no compromise
to ensure that a few years old effort to test
and certify as functional every piece of the
distribution. Redhat, Suse have enterprise
versions of their OSes. Some very expensive
products are _certified_ on big bucks to work
on RHEL or SLES (oracle for example). And for that
reason they(RH,Suse) will rather preffer to backport security
patches only instead of upgrading things and risk
to put down clients with setups worthing tens or
thousands of dollars in licenses to Oracle or
Redhat/ Suse themselves. Mantaining certifications
is a very tough task. It is expensive to obtain,
it is expensive to mantain and it is even
more expensive to pay if you break it.
This is why the best practice is to do backports only.

[Mike Connor (mconnor)]

RHEL 4 ships Firefox 1.0.x based on mozilla.org tarballs, without munging the
app version, so the "you can only certify on a fixed version" argument can go
out the window right now, unless you're saying that RHEL is less concerned with
stability than Ubuntu.

[Jonathan (frixhias)]

Sorry if i was wrong, but i really don't understand this bug things, because the
information it's show in english, and i don't speak english very well. If a
understand in the correct way, this is form reporting a bug on mozilla provided
in ubuntu linux, and for fix this, i have to send this form like a survey or
opinion, if a was wrong, my excuses. It's possible to mention my felicitacioes
and gratefulness by the made work

Friz, Jonathan

[David D Miller (justdave)]

I think the point mconnor is trying to make is that Firefox 1.0.x *is* only
security and stability fixes, with exactly that purpose in mind -- to avoid
breaking things that depend on it. If you want new features and API changes,
that's coming in Firefox 1.1. Since updates to the 1.0.x branch of Firefox
*ARE* security and stability only, there's no reason NOT to actually take them,
since it's exactly what you want anyway.

I'm told that the only non-security fixes to the Firefox 1.0 branch have been
fixing bugs that were introduced by earlier security patches (so by only
backporting security patches and not taking the entire release, you're leaving
your users with new bugs that were not present in 1.0).

[David D Miller (justdave)]

er, I midaired with someone who appears to have resolved this by mistake...

[Vali Dragnuta (vali-dragnuta-asf)]

(In reply to comment #25)
> RHEL 4 ships Firefox 1.0.x based on mozilla.org tarballs, without munging the
> app version, so the "you can only certify on a fixed version" argument can go
> out the window right now, unless you're saying that RHEL is less concerned with
> stability than Ubuntu.

Firefox is one of the few things that are upgraded like this.
Please check any other package from RHEL, and talk later.

[Vali Dragnuta (vali-dragnuta-asf)]

And for those still not understanding the concept
of backporting, please read the following
article by Mark J Cox, Security Response Team Lead
at REDHAT.

http://www.redhat.com/advice/speaks_backport.html

[David D Miller (justdave)]

(In reply to comment #29)
> (In reply to comment #25)
> > RHEL 4 ships Firefox 1.0.x based on mozilla.org tarballs, without munging the
> > app version, so the "you can only certify on a fixed version" argument can go
> > out the window right now, unless you're saying that RHEL is less concerned with
> > stability than Ubuntu.
>
> Firefox is one of the few things that are upgraded like this.
> Please check any other package from RHEL, and talk later.

RHEL doesn't treat Firefox any more special than any other app in this regard.
The 1.0.x version series in Firefox *IS* backports. It is security and
stability only without all the features and bugfixes that go on the trunk.
Mozilla is already doing the backports for you, which is supposed to make life
easier on the distributors.

[great snoopy (great-snoopy)]

> RHEL doesn't treat Firefox any more special than any other app in this regard.
> The 1.0.x version series in Firefox *IS* backports. It is security and
> stability only without all the features and bugfixes that go on the trunk.
> Mozilla is already doing the backports for you, which is supposed to make life
> easier on the distributors.

And if I am a vendor offering support for 3,5 or more years who guarantees me that:
1) as soon as moz 1.1 is out you will update the security patches for 1.0
another 4 years, and IN TIME ?
2) mozilla foundation's leadership and/or policy will not change the next year
and according to the new policy
feature insertions and deletions between minor version will be accepted.
When a very long lifecycle is involved, strange things can happen, even the
complete extinction of
a certain application or product. However the vendor has to be prepared to offer
support for
that app for the whole lifecycle of HIS product - the OS/distro in this case
And after all, it's all about trust : someone can trust mozilla foundation to
stick to the current
policy for the next 3 years or not. I guess I'd rather be prepared for the
worst case scenario
instead to rely on someone else's policy that could eventually change.

[Mike Connor (mconnor)]

(In reply to comment #32)
> And if I am a vendor offering support for 3,5 or more years who guarantees me
that:
> 1) as soon as moz 1.1 is out you will update the security patches for 1.0
> another 4 years, and IN TIME ?

no one that isn't being paid to offer that support guarantees four years of
security patches, unless you commit to doing it yourself, but that's irrelevant
to the current situation, unless your argument is "unless you're going to do it
forever, I'll do it myself starting now." RHEL was single-handedly maintaining
the Mozilla 1.4 branch from when Mozilla 1.7 shipped until recently, when they
changed RHEL 2/3 to the 1.7 branch. I don't anticipate the 1.0.x branch going
away for a long time yet.

> 2) mozilla foundation's leadership and/or policy will not change the next year
> and according to the new policy
> feature insertions and deletions between minor version will be accepted.
> When a very long lifecycle is involved, strange things can happen, even the
> complete extinction of
> a certain application or product. However the vendor has to be prepared to offer
> support for
> that app for the whole lifecycle of HIS product - the OS/distro in this case
> And after all, it's all about trust : someone can trust mozilla foundation to
> stick to the current
> policy for the next 3 years or not. I guess I'd rather be prepared for the
> worst case scenario
> instead to rely on someone else's policy that could eventually change.

If we actually change this policy (though once we're shipping 1.1 or 2.0 or
whatever, why would we backport features to a branch we've been keeping
aggressively API-stable until that point?) then you may have a point. There's a
difference between being prepared to do something if you have to, and doing it,
however. If we announce an end to support of the 1.0 branch.

As a note, Red Hat has one person on the board, and two people on drivers (who
control checkins on the branches). Linux is the main driver for actually having
"stable" branches and continuing to maintain them for very long cycles, so I
can't see arbitrary feature creep come into play. If it _did_ then fine, fork
then, start maintaining your own patches, etc. But why now, when we're going to
a lot of effort to make that unnecessary?

[Wally Gore (wallygor)]

Today I updated to firefox 1.0.4 using synaptic, thinking that this bug was
fixed. It displayes 1.0.4 as the version number, but general.useragent.vendorSub
in about:config is still listed as 1.0. The previously mentioned workaround by
Michael R Head on May 25 still works, though.

[Matt Zimmerman (mdz)]

*** Bug 15130 has been marked as a duplicate of this bug. ***

[Jay Valatka (jvalatka)]

OK, just to make sure I'm within my right to install extensions (as far as
Mozilla is concerned), I first need to make sure I've the latest version of
Firefox using Synaptic.

On my machine, Synaptic says the Installed Version and Latest Version of both
'mozilla-firefox' and 'mozilla-firefox-gnome-support' are 1.0.2-0ubuntu5.3. So
I guess I'm already there.

In Firefox, the about:config page says general.useragent.vendorComment is equal
to 'Ubuntu package 1.0.2 MFSA2005-44'. Now, at least one other commenter has
reported a different value for this particular Preference (comment #23), but
MFSA2005-44 refers to Mozilla's Security Advisory 2005-44 regarding the critical
privilege escalation bug which is resolved by upgrading to Firefox 1.0.4. So it
looks like I just need to do Mike's workaround in comment #3 to get things rolling.

I posted this since I wasn't sure whether others were seeing the same values I
was seeing.

[SlabTzu DeLaFuego (slabtzu)]

(In reply to comment #3)
> Setting general.useragent.vendorSub to 1.0.4 in about:config seems to let me
> access addons.mozilla.org
>
> mike

Hello, please excuse me for not being on your level but "comment 3" makes very
little sence to our Community Center in Harlem which cannot afford a computer
programmer or network engineer to fix our network. We are a social justice
community and desire not to submitto Microsoft.

On behalf of all Ubuntu users who truely believe in the mission for social
justice who are not programmers we ask for basic assistance. Can some one please
put a step by step instructional on how to work the go around that every one
here is talking about (comment 3) until this situation is fixed.

Again, the Linux community is supported by so many people, and many if not most
are not programmers and many are new to computers but not to social justice. We
would appreciate it, if important solutions to issues such as this can be
spelled out for us - that way some of us can fight to defend your jobs,
education, transportation, housing, human rights, etc, and world peace so that
you all can fight for our technology.

DelaFuego ... a fellow activist

[Uphaar Agrawalla (uphaar)]

(In reply to comment #37)
> Can some one please
> put a step by step instructional on how to work the go around that every one
> here is talking about (comment 3) until this situation is fixed.

1. Open Firefox
2. In the Location Bar, type: about:config
3. In the page that opens, there is a field labelled Filters. In this, type:
vendorSub
4. In the list below, you'll see general.useragent.vendorSub. Double click on
it, and enter 1.0.4 in the prompt that opens.
5. Click Ok, and you're set. Now try to access addons.mozilla.org

Hope that helps.

[Go2register (go2register)]

(In reply to comment #3)
> Setting general.useragent.vendorSub to 1.0.4 in about:config seems to let me
> access addons.mozilla.org
>
> mike

[Raj Shekhar (rajlist2)]

If you want to try out the mozilla's firefox, here is what you can do

- download the installer
- Untar it in /tmp
- start the installer (by running sudo ./firefox-installer - you will have to
run it as the admin user)
- when the installer asks you where to place the firefox, point it to /opt/firefox
- the firefox will now install in the /opt/firefox directory
- next run the command `sudo ln -sf /opt/firefox/firefox /usr/bin/firefox `
- do a sudo firefox to make sure your new firefox is running properly
- In case of problem, you can revert back to your ubuntu firefox by running `ln
-sf ../lib/mozilla-firefox/firefox /usr/bin/firefox`

[David D Miller (justdave)]

(In reply to comment #40)
> - do a sudo firefox to make sure your new firefox is running properly

I would strongly advise NOT using sudo to run Firefox (either Ubuntu's or
Mozilla's). When you use sudo, you're running with root privs, and Firefox will
write its preferences to your home directory as root, and then you won't be able
to use or change those preferences again when running Firefox as a normal user.
 This is also unrelated to this bug, so this thread should move to one of the
mailing lists if it needs more replies (ubuntu-users is a good place for it)

[Grayson Chamberlane (pigpen131979)]

(In reply to comment #15)
> When I said,
> "Setting general.useragent.vendorSub to 1.0.4 in about:config seems to let me
> access addons.mozilla.org,"
> I meant that I typed 'about:config' into my location bar, typed
> 'general.useragent.vendorSub' into the search bar that appears on the page,
> double clicked it, and entered 1.0.4.
>
> hope this helps those in need,
> mike

Mike, it helped tremendously. Am a very fresh newbie. who's older bro turned him
onto linux. alot is confussing and due to that i donot touch anything unless i
am certain i understand what i am being told. i simply wanted to change my
firefox theme, an your very clear explanation allowed me to go right where i
needed and get right to the theme selection page. thank you very much.

these forums prove that ubuntu is living up to its name.

[Canukhed (speedabc)]

(In reply to comment #0)
> Mozilla released 1.0.4 firefox, and ubuntu backported fixes to 1.0.2. But,
> mozilla doesn't allow instaling extensions from their site on firefox <1.0.4.
> Since ubuntu's mozilla has 1.0.3 and 1.0.4 fixes, it acctually, is 1.0.4
> firefox. But, version string in programs says 1.0.2.
>
> This is very, hm...., stoopid (?!) situation couse Ubuntu's firefox IS 1.0.4,
> but reports as 1.0.2. But, if version strings remains 1.0.2, users will not be
> able to download/install any exntesions.

[Corey Burger (corey.burger)]

*** Bug 19147 has been marked as a duplicate of this bug. ***

[Erik van Luxzenburg (evanluxzenburg)]

(In reply to comment #15)
That's what I call support! Thnx Mike

[Martin Pitt (pitti)]

Should be fixed in USN-149-2:

 mozilla-firefox (1.0.6-0ubuntu0.1) hoary-security; urgency=low
 .
   * Backporting broke many extensions and introduced other regressions; update
     to the complete 1.0.6 upstream version. (Ubuntu #12882, #12854)
   * browser/app/profile/firefox.js: Revert Ubuntu change of fixing
     general.useragent.vendorSub to "1.0" to be able to install addons again.
     (Ubuntu #10681)

[era (era+ubuntu)]

For whatever it's worth, the Mozilla addons page still tries to persuade me to
upgrade to 1.0.6, although I already did. I have 1.0.6-0ubuntu0.1 and the
vendorSub string in about:config displays 1.0.6 out of the box.

I would take the liberty to reopen, seeing as the symptom doesn't appear to be
cured yet, but Bugzilla won't let me.

[Martin Pitt (pitti)]

(In reply to comment #47)
> For whatever it's worth, the Mozilla addons page still tries to persuade me to
> upgrade to 1.0.6, although I already did. I have 1.0.6-0ubuntu0.1 and the
> vendorSub string in about:config displays 1.0.6 out of the box.

Reopened. Odd, this works fine for me. Does it still happen if you temporarily
move ~/.mozilla aside and use a clean profile?

[era (era+ubuntu)]

Works for me now. Sorry, can't point to what fixed it -- maybe they've done
something over at addons.mozilla.org, or maybe I somehow botched it when I
(thought I) managed to still repro.

[Martin Pitt (pitti)]

(In reply to comment #49)
> Works for me now. Sorry, can't point to what fixed it -- maybe they've done
> something over at addons.mozilla.org, or maybe I somehow botched it when I
> (thought I) managed to still repro.

No worries, thanks for testing it again.