Open Bug 1617634 Opened 5 years ago Updated 2 years ago

[mozproxy] Move pacURL into a template, so we do not have to load the pac script from a data URL

Categories

(Testing :: Mozbase, enhancement, P3)

Version 3
enhancement

Tracking

(Not tracked)

People

(Reporter: freddy, Unassigned)

References

Details

Summary: Moe pacURL into a template, so we do not have to load the pac script from a data URL → Move pacURL into a template, so we do not have to load the pac script from a data URL
Priority: -- → P3
Summary: Move pacURL into a template, so we do not have to load the pac script from a data URL → [mozproxy] Move pacURL into a template, so we do not have to load the pac script from a data URL

Geoff, if I were to do this myself could I change the code in a temporary file (e.g. using mktemp) during startup that is removed after shutdown?
If so, I could just use a file:// URL.

This would help me unblock important Firefox hardening work.

Flags: needinfo?(gbrown)

:tarek -- Can you advise :freddy?

Flags: needinfo?(gbrown) → needinfo?(tarek)
See Also: → 1437585

For the templating part, yeah no problem, we can move the pacURL string to a file, it will be much cleaner. and load it in that function.

For passing it to the browser, the problem of having it into a local file is that you will need to push it to devices when you work with mobile tests (adb push). Unless you temporarely serve it via a local web server, but this adds complexity.

I guess my question is: what is your current issue of passing it trhough a data URL ?

Flags: needinfo?(tarek) → needinfo?(fbraun)

pacURLs are loaded in the parent process and loaded from the SystemPrincipal.
We have some hardening efforts underway that would eventually disallow passing data URLs to privileged contexts, to avoid sandbox escapes and similar escalation of privilege issues.
While we're still a bit further away from restricting this in the parent process, but we are planning to do the SystemPrincpal restriction rather soon (bug 1613609).

I understand that there's indeed added complexity with tests on remote devices (e.g., android).
I don't think I have a much better solution besides your idea - except maybe putting the file into the test profile directory, so it will included in the existing push? Would that be possible?

Flags: needinfo?(fbraun) → needinfo?(tarek)

I would not pollute the profile with a custom file. I think it's best if we specifically push it to the device during the test setup, even though
it adds some complexity.

On the other hand, if you want to add it in the profile, maybe we could add a new "network.proxy.autoconfig_script" pref ?
that could be part of the profile and named "networkProxyConfig.js" or something like this ?

Flags: needinfo?(tarek)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.