Running the mochitests locally always warns about ssltunnel allowing network connections

RESOLVED FIXED in Firefox 64

Status

enhancement
RESOLVED FIXED
Last year
4 months ago

People

(Reporter: kats, Assigned: loganfsmyth)

Tracking

59 Branch
mozilla64
Points:
---

Firefox Tracking Flags

(firefox64 fixed)

Details

Attachments

(1 attachment)

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.
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
(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.
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.
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)
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.
https://hg.mozilla.org/mozilla-central/rev/1bbb6f80f5d9
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Regressions: 1544089
You need to log in before you can comment on or make changes to this bug.