59 bytes, text/x-review-board-request
Since the release of Firefox 57, we are seeing AutoConfig being used by bad actors. Because of that, we are going to be sandboxing AutoConfig to only its original API in Rapid Release version 62. We are not sandboxing on the ESR. The APIs that will be available in AutoConfig on Rapid Release are: pref(prefName, value) – sets the user value of a preference. defaultPref(prefName, value) – sets the default value of a preference. lockPref(prefName, value) – sets the default value of a preference and locks it. unlockPref(prefName) – unlocks a preference. getPref(prefName) – retrieves the value of a preference clearPref(prefName) – removes the user value of a preference, resetting it to its default value. displayError(funcname, message) – displays an error in a specific format. getenv(name) – allows you to query environment variables. We will be removing getPrefBranch and the LDAP APIs (setLDAPVersion, getLDAPAttributes, and getLDAPValue). If anyone requires AutoConfig outside of the standard API, we will be encouraging them to move to the ESR. We also hope for folks to tell us what kinds of things are missing so we can add them to the policy engine.
Mike: for release channel are we allowing access to some subset of preferences, or can anything be set?
(In reply to Mike Kaply [:mkaply] from comment #0) > we are going to be sandboxing AutoConfig to only > its original API in Rapid Release version 62. We are not sandboxing on the > ESR. I thought the plan was to remove this entirely for 62 and later, and to let it live on ESR for one last full cycle. Has the plan changed? If it has, why?
> I thought the plan was to remove this entirely for 62 and later, and to let it live on ESR for one last full cycle. Has the plan changed? If it has, why? The patches from Kris were always about sandboxing the API, not removing it. The policy engine does not provide for arbitrary setting/locking of preferences (and we have no plans to add it at this time). There are legitimate reasons for setting prefs that we don't include. We have no plans to remove Autoconfig from ESR at this time.
It would be possible to keep AutoConfig unrestricted also on test channels (Nightly, aurora and unbranded)? Just like the idea behind allowing these channels to run legacy extensions and disable extension signing requirement. I think the reasoning is the same. Please. =)
> It would be possible to keep AutoConfig unrestricted also on test channels (Nightly, aurora and unbranded) That's probably what will happen, but I'm not sure I see any advantage with that.
> That's probably what will happen, Excellent news, thank you! > I'm not sure I see any advantage with that. With the understandable removal of legacy extensions support, unrestricted AutoConfig seems to be the only remaining way to customize Firefox beyond what is possible to do with WebExtensions API. I understand the security concerns with unrestricted AutoConfig on release channel (and future ESR, I guess), but test channels aimed to people who know the risks should never have this restriction.
> With the understandable removal of legacy extensions support, unrestricted AutoConfig seems to be the only remaining way to customize Firefox beyond what is possible to do with WebExtensions API. What types of customizations are you talking about?
Everything you could do with legacy extensions but can't code with WebExt API. With unrestricted JS you can almost fork Firefox without recompiling it. I use AutoConfig to improve my user experience. Some examples: - Mouse/rocker gestures not limited to page content, working in toolbars (chrome process) too [similar non-WebExt: Mouse Gestures Redox]; - Autoselect the first urlbar popup entry when typing in urlbar (way better than default domain-only autocompleting) [similar non-WebExt: Enter Selects and Mozilla Labs: Prospector - Speak Words]; - Avoid unwanted history removal by accidentally pressing Delete when an item is selected in urlbar popup (I changed it to Shift + Delete); - Status bar [similar non-WebExt: Status-4-Evar]; - When typing things like "node.js" or "layout.word_select.eat_space_to_next_word" in urlbar, even without prefixing them with search engine keyword Fx should load search results with default search engine, not try to load "http://www.node.js/" [similar non-WebExt: speedupcanonizeurl]; - Require master password to startup Firefox (not a big deal, just to drive away friends and family from my Fx profile) [similar non-WebExt: Master Password+]; - Highlight vertical position of Ctrl+F results on scrollbar [Chrome parity, similar non-WebExt: FindBar Tweak]. Etc. I have these and much more in my AutoConfig (it's like a Greasemonkey with userscripts that work as legacy extensions - the name of this 'concept' is userChromeJS). Every Fx update I need to fix things in my code, no problem. I just want that forever there is a way to run unrestricted customized JS code on Fx startup. So if AutoConfig will remain unrestricted on Developer Edition I'm fine with that.
Kris: I'd like to do the LDAP change separately. Trying to get this part done so I can get softvision testing
Comment on attachment 8980031 [details] Bug 1455601 - Sandbox AutoConfig if sandbox_enabled pref is set. https://reviewboard.mozilla.org/r/246200/#review252296 Thanks ::: extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp:101 (Diff revision 2) > const char *filename, bool bGlobalContext, > + bool bCallbacks, bool skipFirstLine, Ugh. Can we get rid of the Hungarian typing while you're here? Below, too... ::: extensions/pref/autoconfig/src/nsReadConfig.cpp:139 (Diff revision 2) > + bool sandboxEnabled = false; > + rv = defaultPrefBranch->GetBoolPref("general.config.sandbox_enabled", > + &sandboxEnabled); We should probably force this to true in release builds... ::: extensions/pref/autoconfig/src/nsReadConfig.cpp:305 (Diff revision 2) > for (uint32_t i = 0; i < amt; i++) > buf[i] -= obscureValue; > } > rv = EvaluateAdminConfigScript(buf, amt, aFileName, > false, true, > - isEncoded ? true:false); > + isEncoded ? true : false, Please just get rid of the ternary rather than fixing the spacing.
Attachment #8980031 - Flags: review?(kmaglione+bmo) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/bcae764555a8 Sandbox AutoConfig if sandbox_enabled pref is set. r=kmag
I think we should have a documentation about "general.config.sandbox" somewhere. Otherwise admins won't notice until Firefox 62 is released.
(In reply to Masatoshi Kimura [:emk] from comment #21) > I think we should have a documentation about "general.config.sandbox" > somewhere. Otherwise admins won't notice until Firefox 62 is released. Policy Engine/AutioConfig stuff is on SUMO, right? https://support.mozilla.org/en-US/products/firefox-enterprise In which case, this is not a dev docs issue. I've need'info'ed Joni here, to see if she knows who to pass this on to (thanks Joni!)
This actually belongs in the beta release notes. Release Note Request (optional, but appreciated) [Why is this notable]: This is a major change for enterprise [Affects Firefox for Android]: No [Suggested wording]: The release version of Firefox 62 will be sandboxing AutoConfig to the documented API. You can test this in Firefox beta by setting the preference general.config.sandbox_enabled to true. If you need to continue use more complex AutoConfig scripts, you will need to use the ESR. [Links (documentation, blog post, etc)]: Should link to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1455601
You need to log in before you can comment on or make changes to this bug.