Closed
Bug 1474895
Opened 6 years ago
Closed 6 years ago
Running the mochitests locally always warns about ssltunnel allowing network connections
Categories
(Testing :: Mochitest, enhancement)
Tracking
(firefox64 fixed)
RESOLVED
FIXED
mozilla64
Tracking | Status | |
---|---|---|
firefox64 | --- | fixed |
People
(Reporter: kats, Assigned: loganfsmyth)
References
Details
Attachments
(1 file)
Run for example:
./mach mochitest -f plain --keep-open=false gfx/layers/apz/test/mochitest/
on macOS. When the test harness starts ssltunnel, macOS shows a dialog asking whether or not to allow/deny network connections. This dialog sits on top of the browser window until the user clicks on one of the buttons, and it can actually interfere with the mochitests that are running.
Even if this just happened the first time it would be acceptable, but it happens *every* time the above command is run. I suspect the ssltunnel binary is getting copied into a new temp location on every run, so macOS doesn't know to apply the allow/deny response from the last run to the new binary, and so prompts again. At the very least we should be able to avoid this. Or even better would be to stop opening the network connection in the first place since the mochitests don't seem to require it (if I click "deny" the tests seem to run just fine).
I've run into this bug on Windows as well, basically the same issue but different dialog because Windows.
Assignee | ||
Comment 1•6 years ago
|
||
This is bugging me too. I'm going to see if I can get this fixed, though we'll have to see if anything pops up that stops my fix from working.
Assignee: nobody → lsmyth
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•6 years ago
|
||
Comment 3•6 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #0)
> Even if this just happened the first time it would be acceptable, but it
> happens *every* time the above command is run. I suspect the ssltunnel
> binary is getting copied into a new temp location on every run, so macOS
> doesn't know to apply the allow/deny response from the last run to the new
> binary, and so prompts again. At the very least we should be able to avoid
> this. Or even better would be to stop opening the network connection in the
> first place since the mochitests don't seem to require it (if I click "deny"
> the tests seem to run just fine).
I don't think we copy the ssltunnel binary anywhere (AFAIK), but it's possible that there's some other weirdness involved that makes firewalls unhappy. Most mochitests don't require ssltunnel running, but any that use HTTPS will in fact fail if it doesn't run.
Assignee | ||
Comment 4•6 years ago
|
||
From what I read, OSX will prompt on every call to Listen on a public address, unless the binary has been signed. I also tried self-signing locally but didn't have any luck. Since loopback seemed like enough anyway, I didn't dig into it much more.
Assignee | ||
Comment 5•6 years ago
|
||
Andrew, do you know anyone else that might be good to review this patch? It seems like lots of people are tentatively happy with it, but it's always a little worrying to land something with no-one giving a firm yes.
Flags: needinfo?(ahal)
Comment 6•6 years ago
|
||
No, :ted would be my top pick though maybe he knows of someone else. I'm also cc'ing :gbrown and :bc as an fyi that this poses some risk to Android tests.
I think landing and seeing what breaks might be the best strategy here :)
Flags: needinfo?(ahal)
Pushed by lsmyth@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1bbb6f80f5d9
Only listen on loopback to avoid constant firewall warnings.
Comment 8•6 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
You need to log in
before you can comment on or make changes to this bug.
Description
•