Closed
Bug 1434655
Opened 7 years ago
Closed 7 years ago
Make AutoConfig ESR only starting with Firefox 60 and add a deprecation message for ESR
Categories
(Core :: AutoConfig (Mission Control Desktop), enhancement)
Tracking
()
RESOLVED
DUPLICATE
of bug 1455601
Tracking | Status | |
---|---|---|
firefox60 | --- | affected |
People
(Reporter: mkaply, Assigned: mkaply)
References
Details
Attachments
(1 obsolete file)
The AutoConfig functionality is being actively used for hijacking and for subverting add-on signing. We've found cases in bug 1292444 and bug 1431934 and I also have had other reports.
With the policy engine coming (bug 1419102), it's time to deprecate AutoConfig (best idea) or at least sandbox it so only the documented API can be used (versus having full access to Components).
We will leave it active on the ESR for now for enterprise users that need it.
I'd also like to remove it on ESR eventually (or again, sandbox it like it was originally intended).
Comment 1•7 years ago
|
||
Updated•7 years ago
|
Attachment #8947161 -
Attachment is obsolete: true
Comment 2•7 years ago
|
||
How much work would it be to sandbox AutoConfig to stop this abuse vector in 59? I think we should both sandbox it AND deprecate it, with removal for ESR-after-60.
Assignee | ||
Comment 3•7 years ago
|
||
Most use of AutoConfig (including CCK2) isn't using the standard API anyway, so sandboxing would still result in major breakage for folks not on ESR. And based on the number of CCK2 issues I've received on Firefox 58, there are quite a few users.
I think we will need to keep AutoConfig on ESR to cover cases that our policy engine won't address at first, possibly looking at completely removal in the next ESR.
My only thought around sandboxing was if we wanted to keep legacy AutoConfig on release and limit it to the original API it was designed for. I don't think we should sandbox on ESR.
Comment 4•7 years ago
|
||
(In reply to Mike Kaply [:mkaply] from comment #3)
> Most use of AutoConfig (including CCK2) isn't using the standard API anyway,
> so sandboxing would still result in major breakage for folks not on ESR. And
> based on the number of CCK2 issues I've received on Firefox 58, there are
> quite a few users.
>
> I think we will need to keep AutoConfig on ESR to cover cases that our
> policy engine won't address at first, possibly looking at completely removal
> in the next ESR.
>
> My only thought around sandboxing was if we wanted to keep legacy AutoConfig
> on release and limit it to the original API it was designed for. I don't
> think we should sandbox on ESR.
Mike, do you see the main set of users affected here as people deploying non-esr builds with cck2? Do we have a sense on what that number looks like?
Assignee | ||
Comment 5•7 years ago
|
||
> Mike, do you see the main set of users affected here as people deploying non-esr builds with cck2?
Yes. And some just Autoconfig users as well.
> Do we have a sense on what that number looks like?
I do not, but I don't think it's incredibly large. Firefox 58 broke CCK2 so I got a sense of how many people would have a problem and it wasn't as bad as I thought.
I think we're really going to have to get the message out that anyone that wants to do anything "enterprisey" with Firefox will need to move over to ESR 60 or whatever we build for them.
Assignee | ||
Comment 7•7 years ago
|
||
Apologize for more duping, but the official bug is going to be bug 1455601.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•