Closed
Bug 790054
Opened 12 years ago
Closed 12 years ago
Disable WPA Enterprise support
Categories
(Firefox OS Graveyard :: General, defect, P2)
Tracking
(blocking-basecamp:+, firefox19 fixed, firefox20 fixed, b2g18 fixed)
People
(Reporter: overholt, Assigned: mrbkap)
References
Details
(Whiteboard: [LOE:S])
Attachments
(2 files, 1 obsolete file)
2.45 KB,
patch
|
vchang
:
review+
|
Details | Diff | Splinter Review |
2.70 KB,
patch
|
fabrice
:
review+
|
Details | Diff | Splinter Review |
Brian states in bug #789217 comment #2 that until bugs #775499 and #789217 are fixed, we should disable WPA Enterprise support. Is this better filed as a Gaia issue?
Updated•12 years ago
|
blocking-basecamp: ? → +
Comment 2•12 years ago
|
||
Before disabling this, can we check there is no other option?
Part of the development team is based in premises where this is the only WiFi security mechanism allowed (see https://bugzilla.mozilla.org/show_bug.cgi?id=775499#c17)
Assignee | ||
Updated•12 years ago
|
Whiteboard: [LOE:S]
Updated•12 years ago
|
Blocks: basecamp-security
Priority: -- → P2
Reporter | ||
Comment 3•12 years ago
|
||
What needs to be done here? Who is the best person to do it?
Flags: needinfo?
Assignee | ||
Comment 4•12 years ago
|
||
(In reply to Andrew Overholt [:overholt] from comment #3)
> What needs to be done here? Who is the best person to do it?
I'd prefer to see this fixed in Gaia. Basically we could disable WPA-EAP support in the backend entirely (which would also be easy) or remove the UI for it in the frontend. This would be a stopgap measure until we have the time and resources to fix bug 789217 which will involve firing events for unrecognized certs.
For developers who only have access to WPA-EAP networks, they could flash a wpa_supplicant.conf to their phone.
Flags: needinfo?
Comment 5•12 years ago
|
||
As Daniel said, we would prefer to fix bug 789217 instead of disabling WPA Enterprise. If it's a problem of resources, we can take over bug 789217 on TEF if you wish.
Comment 6•12 years ago
|
||
Milestoning for C2 (deadline of 12/10), as this meets the criteria of "known P2 bugs found before or during C1".
Target Milestone: --- → B2G C2 (20nov-10dec)
Comment 7•12 years ago
|
||
No update for nearly a month. What needs to happen to move this forward?
Comment 8•12 years ago
|
||
I posted a WIP patch for bug 775499 earlier today. I don't think we should disable EAP at all, we can land the patch for 77499 instead in time which will leave us on par with current Android systems in regard to EAP support and certificate verification.
So in short, I think this bug should be resolved as invalid, and bug 775499 should be marked as blocking instead.
Comment 9•12 years ago
|
||
I don't know enough to make that call. Blake?
Comment 10•12 years ago
|
||
Let's move forward here. See https://bugzilla.mozilla.org/show_bug.cgi?id=775499#c37.
Comment 11•12 years ago
|
||
Thanks Alex. Blake, when can you have a fix for this available?
Comment 12•12 years ago
|
||
Deferring, not really necessary for C2 but it would be good to get this off our list.
Target Milestone: B2G C2 (20nov-10dec) → B2G C3 (12dec-1jan)
Comment 13•12 years ago
|
||
No update from mrbkap since October. What needs to happen here?
Comment 14•12 years ago
|
||
Mrbkap says can fix this week.
Assignee | ||
Comment 15•12 years ago
|
||
This patch no longer shows WPA-EAP networks in the available network list unless they were previously configured. Even after this patch, people can manually patch their wpa_supplicant.conf to connect to WPA-EAP networks.
Assignee | ||
Updated•12 years ago
|
Attachment #694558 -
Flags: review?(vchang)
Comment 16•12 years ago
|
||
Just spoke with Fabrice and here's the following suggestion to move forward on this bug:
*Let's land this bug once the patch has been r+'ed
*Can we add a pref to custom-prefs.js to allow developers/dogfooders to toggle this on if necessary? (We have specific partner needs to be able to use WPA enterprise networks for testing purposes.)
Blake, could you confirm if this is feasible? Thanks.
Comment 17•12 years ago
|
||
One additional note:
*Can we hold off landing this patch until we have a path forward on the 2nd bullet regarding the pref? Thanks.
Assignee | ||
Comment 18•12 years ago
|
||
(In reply to Chris Lee [:clee] from comment #16)
> Blake, could you confirm if this is feasible? Thanks.
Sure, that's easy.
Assignee | ||
Comment 19•12 years ago
|
||
Note: this is untested (I'm at my parents' house and don't have an EAP network to test on. Fabrice, would you mind testing? Note that we read the pref in onsupplicantconnection, which means that it'll be necessary to turn wifi off and on for the pref to take effect. It's easy to fix that restriction, but I don't know if it's worth it.
Feedback: :fabrice
Attachment #694692 -
Flags: review?(vchang)
Assignee | ||
Updated•12 years ago
|
Attachment #694692 -
Flags: feedback?(fabrice)
Comment 20•12 years ago
|
||
Comment on attachment 694692 [details] [diff] [review]
Allow WPA-EAP networks based on a gecko pref.
Review of attachment 694692 [details] [diff] [review]:
-----------------------------------------------------------------
look good with a try { } catch(e){} to not blow up.
::: dom/wifi/WifiWorker.js
@@ +1784,5 @@
> self._enableAllNetworks();
> WifiManager.saveConfig(function() {})
> });
>
> + self._allowWpaEap = Services.prefs.getBoolPref("b2g.wifi.allow_unsafe_wpa_eap");
I think that will throw if the pref is not defined at all.
Attachment #694692 -
Flags: feedback?(fabrice) → feedback+
Comment 21•12 years ago
|
||
Comment on attachment 694558 [details] [diff] [review]
patch, v1
Review of attachment 694558 [details] [diff] [review]:
-----------------------------------------------------------------
Looks good.
Attachment #694558 -
Flags: review?(vchang) → review+
Comment 22•12 years ago
|
||
(In reply to Vincent Chang[:vchang] from comment #21)
> Comment on attachment 694558 [details] [diff] [review]
> patch, v1
>
> Review of attachment 694558 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> Looks good.
I have verified this patch, it looks good.
Comment 23•12 years ago
|
||
Comment on attachment 694692 [details] [diff] [review]
Allow WPA-EAP networks based on a gecko pref.
Review of attachment 694692 [details] [diff] [review]:
-----------------------------------------------------------------
It will throw if the pref is not defined.
Do we need to hook it to settings ?
Attachment #694692 -
Flags: review?(vchang) → review-
Assignee | ||
Comment 24•12 years ago
|
||
This adds the needed try/catch. I don't want to make this a setting as I don't think this is a gaia-level decision. If the user wants to open him/herself up to bug 775499 that's something I'd prefer that they do themselves in a very out-of-the-ordinary way. We should also try to get this patch in sooner rather than later and if people want, adding a setting as well as (or in addition to) the pref can be done in a followup.
Attachment #694692 -
Attachment is obsolete: true
Attachment #694961 -
Flags: review?(vchang)
Updated•12 years ago
|
Attachment #694961 -
Flags: review?(vchang) → review+
Assignee | ||
Comment 25•12 years ago
|
||
Comment 26•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b256fb454e3c
https://hg.mozilla.org/mozilla-central/rev/911c7371b8b3
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 27•12 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•