Allow build time configuration of the system extension search path

RESOLVED WONTFIX

Status

()

Toolkit
Add-ons Manager
RESOLVED WONTFIX
10 years ago
2 years ago

People

(Reporter: Colin Walters, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [intent-to-close])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

10 years ago
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
(Assignee)

Updated

10 years ago
Product: Firefox → Toolkit
Would take a patch here I think, but not going to actively work on it.
Created attachment 381064 [details] [diff] [review]
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 on attachment 381064 [details] [diff] [review]
patch

Can you please review this one?
Attachment #381064 - Flags: review?(dtownsend)
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.
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).
(Reporter)

Comment 6

9 years ago
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).
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.
(Reporter)

Comment 8

9 years ago
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.
(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.
Created attachment 381746 [details] [diff] [review]
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.
Attachment #381064 - Attachment is obsolete: true
Attachment #381064 - Flags: review?(dtownsend)
Attachment #381746 - Flags: review?(dtownsend)
Attachment #381746 - Flags: review?(dtownsend) → review-
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
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.
Summary: developer ability to override system extension search path → Allow build time configuration of the system extension search path
(Reporter)

Comment 13

9 years ago
(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
(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.
(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

2 years ago
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.
Whiteboard: [intent-to-close]

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.