412446 - Allow build time configuration of the system extension search path

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Colin Walters]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b2pre) Gecko/2008011409 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b2pre) Gecko/2008011409 Minefield/3.0b3pre

Bug #311008 adds a default "system install" location for extensions.  However, it would be nice for developers to be able to override this.  For example the "jhbuild" system allows compiling a lot of software in a separate filesystem prefix, and ideally a jhbuild-ed mozilla would pick up jhbuild-ed Firefox extensions.  Something like MOZ_SYSTEM_EXTENSIONS_PATH or the like.



Reproducible: Always

Comment 1

[Dave Townsend [:mossop]]

Would take a patch here I think, but not going to actively work on it.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Attachment: patch

This patch:

- provides ability to override system extension path (/usr/lib/mozilla/extensions) by MOZ_SYSTEM_EXTENSIONS_PATH environment variable

- adds new extension directory specified by MOZ_EXTENSIONS_PATH environment variable

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Comment on attachment 381064 [details] [diff] [review]
patch

Can you please review this one?

Comment 4

[Dave Townsend [:mossop]]

I had read this request as talking about changing the system install locations at compile time, not at runtime using environment variables. And I don't think we want to add yet another install location at this time. Copying in bsmedberg for his input.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

The environment variable gives us flexibility to define extension directory in firefox shell startup script. By this, we can register extensions regard to the current system state (e.g. current language).

Comment 6

[Colin Walters]

Hm, it seems better to me to do the language-extension association you're talking about in the core code.  If the firefox startup script is setting this variable, then it isn't useful for the developer case I was talking about originally (jhbuild scenario).

Comment 7

[Christopher Aillon (sabbatical, not receiving bugmail)]

Actually, I was hoping this could take something like a colon-separated list instead of just one dir, which would indeed help solve your case Colin.

Comment 8

[Colin Walters]

Ok, if the startup script extended the variable rather than overwrite it (something like MOZ_EXT_PATH="${MOZ_EXT_PATH}:/usr/lib/firefox/$LANG/" that would work.

But it still seems cleaner to me have the language work done in the code rather than the startup script.

Comment 9

[Martin Stránský [:stransky] (ni? me)]

(In reply to comment #7)
> Actually, I was hoping this could take something like a colon-separated list
> instead of just one dir, which would indeed help solve your case Colin.

Yeah, that was my first plan and I'm willing to prepare such patch if there's a chance to get it into tree.

Comment 10

[Martin Stránský [:stransky] (ni? me)]

Attachment: v2 with directory list

There is an updated one. Extension directories are get from MOZ_EXTENSIONS_PATH system variable as a normal directory list like plugin dirs.

Comment 11

[Dave Townsend [:mossop]]

Comment on attachment 381746 [details] [diff] [review]
v2 with directory list

Configuring install locations based on environment variables is not something we want. If nothing else it opens a can of worms where I know there are bugs

Comment 12

[Dave Townsend [:mossop]]

Clarifying the bug summary, though whether the build guys would even be ok taking an additional flag to control this I don't know. It seems more easily solved with a small patch.

Comment 13

[Colin Walters]

(In reply to comment #12)
> Clarifying the bug summary, though whether the build guys would even be ok
> taking an additional flag to control this I don't know. It seems more easily
> solved with a small patch.

Which part?  There are two separate issues here.

* An environment variable for developers who are building Firefox into separate buildroots, and want it to be able to pick up extensions from inside that buildroot (right now /usr/lib/firefox is hardcoded I believe, even if a different --prefix is given).  An example of this is say the Beagle Firefox extension.

* An implementation means for locale-specific extensions

Comment 14

[Dave Townsend [:mossop]]

(In reply to comment #13)
> (In reply to comment #12)
> > Clarifying the bug summary, though whether the build guys would even be ok
> > taking an additional flag to control this I don't know. It seems more easily
> > solved with a small patch.
> 
> Which part?  There are two separate issues here.

About what the original summary was about, being able to change the default system install location for extensions. Nothing about locales specific extensions.

Comment 15

[Martin Stránský [:stransky] (ni? me)]

(In reply to comment #11)
> (From update of attachment 381746 [details] [diff] [review])
> Configuring install locations based on environment variables is not something
> we want. If nothing else it opens a can of worms where I know there are bugs

If a security is the issue here, we can place the extension directory origin to current firefox installation dir and the env variable will point to a subdirectory here. Like "/usr/lib/firefox/" + $MOZ_EXTENSIONS_PATH.

It should sort out all sec. issues, if the attacker has a permission to write to firefox install dir, he/she can install any extension anyway. And we can restrict dirs like ".." and "~".

Comment 16

[Andy McKay]

Due to a long period of inactivity on this bug (6.85 years), I am intending to close this bug within a month or so in accordance with: https://wiki.mozilla.org/Add-ons/OldBugs Please remove [intent-to-close] from the whiteboard and comment on this bug if you would like to keep it open.