Bug 136080

Please, can we disable the current disable-software-update patch for
now so that extensions can be upgraded again?

Being not able to upgrade potential insecure extensions is much more
worse than a non-working feature (firefox update).

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

We are all in agreement that the update feature of extensions and
themes should be reinstated.  However caillon and blizzard have higher
priorities to deal with now.  The fastest way to solve this issue is
if someone submits a replacement patch that disables ONLY the firefox
update.

There is no good way to do this currently within our limitations because of RPM.
 Ben Goodger is aware of this; I talked with him about it in person at the
Mozilla Foundation and it is planned work for Firefox 1.1.

No, the fastest way (perhaps 30 seconds of work) would be to disable
the mentioned patch for now and wait for an upstream solution.

Disabling the patch is quite silly when you consider that the reason this is an
issue at all is because people are downloading and installing random software
from the internet.  There is always going to be a game of cat and mouse when
dealing with that.  You aren't even guaranteed that you are going to get
extension updates for security issues.  It's up to the extension author.  If
they don't know, don't care, or don't have time, then you're still screwed.

But currently, I am screwed everytime -- even when the extension author provides
security updates. I would have to open the extension dialog, visit the homepage
of the plugin, locate the download-link and install it manually. For 10-20
installed extensions, this will be a very time-consuming procedure. Nobody will
do this regularly which would be required for a secure system.

I agree, that the current firefox extension concept is an horror for
system-administrators (not working without X, extensions not signed, installed
extensions do not survive firefox updates, no removal procedure), but:

- the shipped firefox allows to install extensions; perhaps you should put
  | pref_locked("xpinstall.enabled", False)
  into a global configuration file. Ok, people will hate you and every FC 
  review will complain about the crippled firefox. But the system will be
  secure...

- upgrading firefox with the software-update method will probably not work 
  because of access restrictions. So the whole patch does not have any positive 
  effect overall.

Re comment #5: I don't think an upstream solution is going to be quick
in coming, since the upstream goals are likely to differ from ours.
("Don't use RPM -- we make a nice fancy installer!" [--fake quote])

I'll work on a reduced patch today if I get a chance.

Created attachment 107565 [details]
new patch leaves extension-update intact

Attached is a version of the software-update patch which leaves extension
updating intact. 

It leaves in the app.update.autoUpdateEnabled pref too, but makes it 'false' by
default. I'm not certain that's the right choice, but it seemed less intrusive.

Patch removes the GUI for turning that pref back on, but leaves the option to
toggle extension auto-update.

And, most importantly from my point of view, the "Update" button in the
extensions manager is back.

It's a pretty small patch:

$ diffstat firefox-1.0-software-update-leaveextensions.patch
 app/profile/firefox.js 			 |    4 ++--
 components/prefwindow/content/pref-advanced.xul |    4 ++++
 2 files changed, 6 insertions(+), 2 deletions(-)

Upstream totally agrees with us here.  As I said, Ben has a fix in
mind.  Right now, their focus is on merging firefox back to cvs HEAD.
 When that is done, I expect a fix shortly.  If you want something
more immediate, then perhaps a better course of action would be to
flag down Ben on IRC and get him to share his thoughts as to what
should happen, and do that.  From what I understand, it shouldn't be
too much work.

I've checked on irc.mozilla.org a couple of times, and have been
unsuccessful at finding Ben to "flag down".

As per Warren's comment #3, I think my patch is the right thing to do
for  now. There may be some fancier extension management system in the
future, but utterly breaking the current one and hoping for a better
tomorrow doesn't seem like the right approach to me.

Instead, let's leave the completely-doesn't-work-with-Fedora/rpm
browser update system disabled, but not cripple the ability to update
user-installed and user-owned extensions.

Alternately, if you can summarize for me some different approach that
makes sense, I'll be happy to work on it.

Matthew, your patch is good, BUT it should not remove the "Check Now"
button.  ALSO, it would be better to visibly disable the application
update checkbox with some explanatory text (leave the box and allow it
to be set, but have the text greyed out with a parenthetical
explaination "(this is an rpm distribution, use rpm to update
firefox)" of the disabling)...

Also, does your patch catch the case where people have the preference
set in their preferences already?  New profiles would default to
disabled app updates, but old profiles would still get application
update behaviour but lack a way to turn it off via the preferences dialog.

Finally, i do think it is fitting to discourage use of firefox's
application update, but I DON'T think its good to disable it entirely.
 I think it would be better to leave the feature operational but add a
few shrill confirmation dialogs recommending apt/yum/rpm for updates.

-- stig

+1 on comment 12

> Finally, i do think it is fitting to discourage use of firefox's
> application update, but I DON'T think its good to disable
> it entirely. I think it would be better to leave the feature 
> operational but add a few shrill confirmation dialogs recommending 
> apt/yum/rpm for updates.

Well, the problem is that it *isn't* operational -- if you leave the
feature there, it just plain doesn't work. (It might do something if
you're running as root, which you shouldn't be, but then it will just
mess up your system. If you're running as a normal user, it very
confusingly just fails.) Fixing it to actually work would be a major
undertaking.

> Also, does your patch catch the case where people have the 
> preference set in their preferences already?  New profiles would 

It changes the default; I believe that only settings changed from the
default are saved to the user's profile, so that should be okay in
most cases.

Because Firefox 1.1 will not appear before June (which is *after* FC4), we can
not wait for an upstream solution as suggested by comment #4.

We've been using my patch here since December, and it works fine.

This patch still applies to the 1.0.1 update, by the way, and I still believe
that it is the right thing to do until some magical real solution is available.

This patch still applies to the 1.0.2 update, by the way, and I still believe
that it is the right thing to do until some magical real solution is available.

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

Tested patch with the 1.0.3 update; still appears to apply cleanly and work fine.

inclusion of the latest patch to fc4's firefox would be great!

> Tested patch with the 1.0.3 update; still appears to apply cleanly
> and work fine.

I am running Firefox version 1.0.3-1.3.1 from Freshrpms updated by Synaptic/Apt.

Would you please explain exactly what you are talking about here?  The files
addressed in your patch (firefox.js and pref-advanced.xul) do not exist.

I'm not the only one with this problem...

See http://www.redhat.com/archives/rhl-list/2004-December/msg02716.html

As you can see, nobody answered this poster.  What is going on here??  I and the
poster and probably everybody else except you cannot apply your patch.

Mr. or Ms. Akjlsdfhklajsr -- the patch applies to the source, not to the files
installed on your system by the binary (i386) RPM. This is normal and will be
the case for most patches you find in bugzilla (or anywhere).

If you'd like to learn about this, ask me on the Fedora list and I'll respond in
more detail -- it's really not an issue for this bug.

Created attachment 113966 [details]
Enables software update for themes/extensions for Firefox 1.0.3

Mr. Miller,

I am the poster with the funky email address.  I just not managed to get my
personal mail server up and running so I can now come out as myself correctly.

Your patch simply does NOT work with the current Fedora Firefox src rpm.  I got
mine as:
http://ayo.us5.freshrpms.net/fedora/linux/3/i386/RPMS.updates/firefox-1.0.3-1.3.1.i386.rpm


Your patch ignores the application of firefox-PR1-software-update.patch to this
source set.  Also, your patch removes the "Update Now" button from the
Preferences Advanced dialog which I wanted.

So, here is a patch that works for me (YMMV). This patch adds a patch file to
the SOURCES directory and modifies the SPEC file to apply it upon rpmbuild
invocation.

Instructions for patch are:
1. Download the attached patch to the home directory of the rpmbuilder, be it
root or wherever else; calling the downloaded file
'firefox-rpmsrc-swupdate.patch', or whatever else.  If the file is called
something else, that filename needs to be used below.
2. Install the above firefox source rpm in the rpm directory (rpm -ivh ...)
3. `cd' to the rpmbuild root directory (/usr/src/redhat or a non-root location
if building rpms as other than root)
4. Apply this patch to the firefox source installation as:
patch -p1 <~/firefox-rpmsrc-swupdate.patch
5. Build the rpms as usual (rpmbuild -ba --target=i386 SPEC/firefox.spec) and
install/update the binaries to now have a firefox running on Fedora Core 3 that
updates extensions and themes.

Oh, I see your problem. The patch *replaces* the
firefox-PR1-software-update.patch -- it seemed unnecessary (and prone to errors
as the upstream code changes) to patch the software update code out and then
patch part of it back in.

If you leave the Update Now button in the prefs dialog, does it do the right
thing and *only* check for updated extensions and themes? What if the pref for
checking the app itself was enabled *before* the checkbox to change that pref
was hidden? That's why I left it out before.

How do I know for sure if it is only checking for extensions and themes?  I
*think* it is... I know that I was finally able to update a LOT of extensions
that had been stagnant for a long time in my Linux installation.  As for it
checking for the application update, also, I don't know...

Maybe just compile out completely the app update preference as the PR1 does
instead of messing around with it at all?

After re-reading (and double-checking) my comment #14 above, I believe that it
would be no problem to reinstate the Check Now button in the advanced
preferences. I'll update the patch to leave that in. 

You need to address the problem of failure to be applied due to application of
the PR1 patch at normal installation and build of the source rpm. How exactly is
your patch to be applied?  Please provide complete usage instructions.

Are you saying that your patch is to be dropped into the SOURCES directory under
the name of "firefox-PR1-software-update.patch", replacing the original patch ?
 Because, if the SPEC file is not modified to apply another patch as my
"meta-patch" does, then that is what must be done for your patch to work at all.
 Sliding in a patch under the covers and naming it the same as an existing patch
is not acceptable.

Stephen -- I'm not trying to provide an end-user solution here. It's not meant
to be an "after-the-fact" patch. Replacing the original patch is indeed the idea
-- *and the correct thing to do*.

Please don't clutter up this bug with more about it -- e-mail me directly or
post on the mailing list if you have further questions. But to head them off,
here's the here's the instructions:

1. Save the attached patch (will provide new version in a second) as 
   "firefox-1.0.3-remove-software-update-but-leave-extensions.patch"

2. Find the line in the firefox spec file that says:
   "Patch25:        firefox-PR1-software-update.patch"

3. Change that line to:
   "Patch25: firefox-1.0.3-remove-software-update-but-leave-extensions.patch"

4. Find the line later which says "%patch25 -p0" and change it to 
   "%patch25    -p1".

5. And there you are.

If it makes you happier to use a different number entirely, you could do that too.

Created attachment 114007 [details]
firefox-1.0.3-remove-software-update-but-leave-extensions.patch

$ diffstat firefox-1.0.3-remove-software-update-but-leave-extensions.patch
 app/profile/firefox.js 			 |    4 ++--
 components/prefwindow/content/pref-advanced.xul |    3 ---
 2 files changed, 2 insertions(+), 5 deletions(-)

As you can see, this is a very small change -- much smaller than the current
firefox-PR1-software-update.patch. All it does is change the default for the
main software update prefs, and removes the one checkbox for turning it back
on.

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

Is there any updates to this bug? ie.. does the firefox 1.5 builds in Fedora
Devel at least have extension updating enabled??

Yes, in firefox 1.5 in devel there is a 'Find Updates' button in the extensions
window and it appears to work. There is also a 'Find updates' button for themes. 
There are update prefs for 'firefox' 'installed extensions and themes' and
'search enegines'. 

The firefox update pref looks to have some issues. It was not selected by
default, I selected it and then it greyed out and I can't unselect it. 

This has worked for ages now, right? Closing...