Closed Bug 396510 Opened 13 years ago Closed 11 years ago
Remove EM command line global installation capability (e
.g . -install-global-extension and -install-global-theme)
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.
I was going to suggest this at some point my self. Administrators can install system wide addons without having to even run firefox.
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?
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.
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?
Whiteboard: [sg:want P3]
That's Bug 396196
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.
(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?
(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
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.
Yes, that is required to stay anyway so that extensions can be shipped with the application
Target Milestone: --- → mozilla1.9.2
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.
Assignee: nobody → dtownsend
Status: NEW → ASSIGNED
Attachment #376398 - Flags: review?(robert.bugzilla)
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
Attachment #376398 - Flags: review?(robert.bugzilla) → review+
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.9.2 → mozilla1.9.2a1
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
Status: RESOLVED → VERIFIED
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.
(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.
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?
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.
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?
(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.
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
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.
Fixed now. Sorry about the derail. http://forums.mozillazine.org/viewtopic.php?p=8579915#p8579915
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?
Whiteboard: [sg:want P3] → [sg:want P3][need to fix release notes, see comment 24]
You need to log in before you can comment on or make changes to this bug.