Last Comment Bug 396510 - Remove EM command line global installation capability (e.g. -install-global-extension and -install-global-theme)
: Remove EM command line global installation capability (e.g. -install-global-e...
Status: VERIFIED FIXED
[sg:want P3][need to fix release note...
: relnote
Product: Toolkit
Classification: Components
Component: Add-ons Manager (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla1.9.2a1
Assigned To: Dave Townsend [:mossop]
:
: Andy McKay [:andym]
Mentors:
Depends on:
Blocks: 493875
  Show dependency treegraph
 
Reported: 2007-09-17 18:20 PDT by Robert Strong [:rstrong] (use needinfo to contact me)
Modified: 2010-05-12 14:18 PDT (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch rev 1 (9.83 KB, patch)
2009-05-08 05:56 PDT, Dave Townsend [:mossop]
robert.strong.bugs: review+
Details | Diff | Splinter Review

Description Robert Strong [:rstrong] (use needinfo to contact me) 2007-09-17 18:20:57 PDT
These were added for Firefox 1.0 since there was no way to install extensions to the application's extensions directory. Removing this capability removes an attack vector that has been used in several proof of concepts as of late and I believe it can now be removed since it is possible to install add-ons by placing the extracted add-on into a directory named with the add-on's id into the application's extensions directory or the xpi into the application's directory if the user that launches next has write access.

The main thing blocking this IMO is that the doc's should be updated to provide better information on how to deploy add-ons using the place the add-on directory method.
Comment 1 Dave Townsend [:mossop] 2007-09-18 02:10:14 PDT
I was going to suggest this at some point my self. Administrators can install system wide addons without having to even run firefox.
Comment 2 Mike Kaply [:mkaply] 2007-09-18 09:31:50 PDT
Well it is a little painful for administrators. You have to unzip the XPI, Read the install.rdf to get the ID, then create the directory and unzip into it.

The problem is that the directory name is the ID which is bundled up in the XPI.

Maybe we can provide some external utility to do this?
Comment 3 Robert Strong [:rstrong] (use needinfo to contact me) 2007-09-18 13:08:56 PDT
I think a utility would be appropriate... it should be simple enough to accomplish with an extension using a toolkit id with ui made available via its options.
Comment 4 Jesse Ruderman 2007-09-18 20:34:04 PDT
Even if these are removed, attackers will still be able to use -P, so we should probably also do the "register something other than firefox.exe as the default browser" thing.  Is there a bug on that?
Comment 5 Robert Strong [:rstrong] (use needinfo to contact me) 2007-09-18 20:37:03 PDT
That's Bug 396196
Comment 6 Dave Townsend [:mossop] 2008-06-13 05:53:22 PDT
I think we should probably be deprecating the install to application directory. We have other OS-wide install locations on all platforms now, whatever utility we create to replace these command line arguments can install there. This will be safer in the long run, we already have had to make the installer automatically remove certain extensions in the app dir if they exist.
Comment 7 Henrik Skupin (:whimboo) 2008-06-13 06:03:58 PDT
(In reply to comment #6)
> We have other OS-wide install locations on all platforms now, whatever utility

Do you have a bug # off-hand where the implementation was done? Or where can be found some more information about?
Comment 8 Dave Townsend [:mossop] 2008-06-13 06:07:07 PDT
(In reply to comment #7)
> Do you have a bug # off-hand where the implementation was done? Or where can be
> found some more information about?

Windows has had them for pretty much ever, others were done in bug 311008 and related
Comment 9 Mike Kaply [:mkaply] 2008-06-13 07:18:32 PDT
Just to be clear, extensions will still be allowed in the global extensions directory, there will just be no Firefox mechanism to put them there automatically.
Comment 10 Dave Townsend [:mossop] 2008-06-13 07:21:43 PDT
Yes, that is required to stay anyway so that extensions can be shipped with the application
Comment 11 Dave Townsend [:mossop] 2009-05-08 05:56:59 PDT
Created attachment 376398 [details] [diff] [review]
patch rev 1

This drops the command line options. I've also dropped the commandLine argument from the EM's start method. It isn't used and I can't think of a reason why we might ever need it.

I don't think we need tests for this as it is basically code removal. So long as all current tests pass we should be good. The code in question was untested anyway.
Comment 12 Robert Strong [:rstrong] (use needinfo to contact me) 2009-05-11 11:09:09 PDT
Comment on attachment 376398 [details] [diff] [review]
patch rev 1

>diff --git a/toolkit/mozapps/extensions/public/nsIExtensionManager.idl b/toolkit/mozapps/extensions/public/nsIExtensionManager.idl
>--- a/toolkit/mozapps/extensions/public/nsIExtensionManager.idl
>+++ b/toolkit/mozapps/extensions/public/nsIExtensionManager.idl
You should be able to also remove interface nsICommandLine;

With that r=me
Comment 13 Dave Townsend [:mossop] 2009-05-12 01:24:32 PDT
Landed: http://hg.mozilla.org/mozilla-central/rev/c61c8e18dba6
Comment 14 Henrik Skupin (:whimboo) 2009-05-13 07:13:37 PDT
Verified fixed with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090513 Minefield/3.6a1pre ID:20090513034237

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090513 Minefield/3.6a1pre ID:20090513044918
Comment 15 Dimas 2009-12-28 03:37:04 PST
I'm an admin of a 500+ computers company with Firefox on all of them. I need all users have some corporate extensions installed by default, and until FF 3.6 I can do it with batch scripts, netlogon and -install-global-extension command.

Ok, now you have decided to disallow that command, so I've updated the script to copy the xpi to the app 'extensions' directory. But I don't want that every time I update the extensions or install new ones the users can choose to install or not these. Is there an option (user_pref) to disable that alert?

I hope that... if not, I've to stay with FF 3.5 or maybe try another browser.
Comment 16 Dave Townsend [:mossop] 2009-12-28 07:59:24 PST
(In reply to comment #15)
> Ok, now you have decided to disallow that command, so I've updated the script
> to copy the xpi to the app 'extensions' directory. But I don't want that every
> time I update the extensions or install new ones the users can choose to
> install or not these. Is there an option (user_pref) to disable that alert?

You should be extracting the xpi to the appropriately named folder in the extensions folder, not just copying it there. Ask in the appropriate newsgroups or support forums if you cannot get that to work.
Comment 17 Stephen Thomas 2010-01-29 06:54:24 PST
I just wrote a little script that does exactly that, but it doesn't achieve much. The unpacked xpi's all show up correctly in Tools->Addons, but none of them actually *do* anything.

There is a definite need for an easily scripted administrative method for performing a silent system-wide extension install that an end user can't possibly break by clicking the wrong button. The -install-global-extension parameter used to do exactly that, and I'm sure I won't be the last netadmin to find my way into this bug report after spending many fruitless hours trying to work around its removal.

To reduce future noise here, could a developer perhaps post a link to a clear description of the mechanism we are supposed to use instead?
Comment 18 Robert Strong [:rstrong] (use needinfo to contact me) 2010-01-29 06:59:37 PST
One easy surefire way to do this is to install the extension normally, then take the directory for the newly installed extension in the profile inside the extensions directory, and then copy it to the installation directory's extensions directory. The first two steps only need to be done once per extension.
Comment 19 Stephen Thomas 2010-01-29 19:06:09 PST
From a netadmin point of view, that looks like a time-wasting manual repackaging chore. What did -install-global-extension used to put in an installed extension's directory other than the unzipped contents of the xpi, and is there a straightforward way to generate that extra stuff from the xpi alone?
Comment 20 Dave Townsend [:mossop] 2010-01-29 19:28:16 PST
(In reply to comment #19)
> From a netadmin point of view, that looks like a time-wasting manual
> repackaging chore. What did -install-global-extension used to put in an
> installed extension's directory other than the unzipped contents of the xpi,
> and is there a straightforward way to generate that extra stuff from the xpi
> alone?

Nothing extra was ever put into the directory. Rob's suggestion just makes sure you get the directory name right etc.
Comment 21 Stephen Thomas 2010-01-29 19:57:53 PST
For what it's worth, my little script got its directory names from the first <em:id> line inside the xpi's own install.rdf; the names it picked matched those used by -install-global-extension on another computer for the same set of xpi files. I believe I have the directory names right.

I'd like to know what else I should check (what is "etc."?) but this is surely the wrong place for debugging my own code, so I've opened a forum thread:

http://forums.mozillazine.org/viewtopic.php?f=7&t=1724155
Comment 22 Robert Strong [:rstrong] (use needinfo to contact me) 2010-01-29 23:54:11 PST
You can try the method I suggested and compare it against the end result of your script to get an idea as to what is different / why it isn't working.
Comment 23 Stephen Thomas 2010-01-30 01:34:05 PST
Fixed now. Sorry about the derail.

http://forums.mozillazine.org/viewtopic.php?p=8579915#p8579915
Comment 24 Stephen Thomas 2010-02-05 17:58:16 PST
The current release notes explain a procedure for moving an extension from locally installed to global:

http://www.mozilla.com/en-US/firefox/3.6/releasenotes/#troubleshooting

Is that whole paragraph now obsolete, or only the part that mentions -install-global-extension?

Note You need to log in before you can comment on or make changes to this bug.