On 5/10/15 10:29 AM, Tal Einat wrote:

On Sun, May 10, 2015 at 5:07 PM, Brett Cannon mailto:brett@python.org> wrote:

On Sun, May 10, 2015 at 10:04 AM Skip Montanaro mailto:skip.montanaro@gmail.com> wrote:

I haven't run the test suite in awhile. I am in the midst of running it on my Mac running Yosemite 10.10.3. Twice now, I've gotten this popup:

​ I assume this is testing some server listening on localhost. Is this a new thing, either with the Python test suite or with Mac OS X? (I'd normally be hidden behind a NAT firewall, but at the moment I am on a miserable public connection in a Peet's Coffee, so it takes on slightly more importance...)

It's not new.

Indeed, I've run into this as well.

I've also seen the Crash Reporter pop up many times, but as far as I could tell, in all cases the test suite output told me it was expected. Perhaps tests which listen for network connections should also mention that, at least on Macs?

Wouldn't hurt. Just requires tracking down which test(s) triggers it (might be more than one and I don't know if answering that popup applies for the rest of the test execution or once per test if you use -j).

If anyone starts working on this, let me know if I can help, e.g. trying things on my own Mac.

I believe that the message has to do with OS X's sandboxing implementation and the setting of the sandbox's entitlement keys. Here's an Apple doc: https://developer.apple.com/library/ios/documentation/Miscellaneous/Referenc... I'm unaware of a way to work around this other than using Apple's code signing or adjusting target build settings in XCode :( If anyone knows a good way to workaround or manually set permission (other than clicking the Allow button), I would be interested. Warmly, Carol -- *Carol Willing* Developer | Willing Consulting https://willingconsulting.com

In article , Tal Einat wrote:

...

...

On Sun, May 10, 2015 at 10:04 AM Skip Montanaro wrote:

...

I haven't run the test suite in awhile. I am in the midst of running it on my Mac running Yosemite 10.10.3. Twice now, I've gotten this popup: I assume this is testing some server listening on localhost. Is this a new thing, either with the Python test suite or with Mac OS X? (I'd normally be hidden behind a NAT firewall, but at the moment I am on a miserable public connection in a Peet's Coffee, so it takes on slightly more importance...) It's not new. Indeed, I've run into this as well. I've also seen the Crash Reporter pop up many times, but as far as I could tell, in all cases the test suite output told me it was expected. Perhaps tests which listen for network connections should also mention that, at least on Macs? Wouldn't hurt. Just requires tracking down which test(s) triggers it (might be more than one and I don't know if answering that popup applies for the rest of the test execution or once per test if you use -j). If anyone starts working on this, let me know if I can help, e.g. trying

On 5/10/15 10:29 AM, Tal Einat wrote: On Sun, May 10, 2015 at 5:07 PM, Brett Cannon wrote: things on my own Mac. \> > I believe that the message has to do with OS X's sandboxing implementation and the setting of the sandbox's entitlement keys. Here's an Apple doc: https://developer.apple.com/library/ios/documentation/Miscellaneous/Referenc e/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple_ref/doc/u id/TP40011195-CH4-SW9 I'm unaware of a way to work around this other than using Apple's code signing or adjusting target build settings in XCode :( If anyone knows a good way to workaround or manually set permission (other than clicking the Allow button), I would be interested. I was reading about this a few weeks ago an recall finding a way to ad-hoc sign the built python executable. Here's a link below. I haven't tried

On Sun, May 10, 2015 at 9:07 PM, Carol Willing < willingc@willingconsulting.com> wrote: this, though, and don't know if it would work with a python executable rather than a proper OSX app. If it does work, it would be useful to add this as a tool and/or mention it in the developer docs.

http://apple.stackexchange.com/a/121010

I believe the issue has to do with the OS X application firewall and not sandboxing, as vanilla Python on OS X is not sandboxed. See: https://support.apple.com/en-us/HT201642 As described there, codesigned applications are automatically authorized to accept inbound connections; that's the workaround proposed in the apple.stackexchange cite. But arbitrarily signing development binaries after every compile is probably not a good idea. Another option is to configure the firewall but that probably only can be made to work with a framework build of Python which launches Python within an app bundle. In any case, please open an issue on the bug tracker so we can follow up on this. -- Ned Deily, nad@acm.org

Twice now, I've gotten this popup: ...

Let me improve my request, as it seems there is some confusion about what I want. I'm specifically not asking that the popups not be displayed. I don't mind dismissing them. When they appear, I would, however, like to glance over at the stream of messages emitted by the test runner and see a message about it being expected. It seems that the tests which can trigger the crash reporter do this. If I get a chance, I will look into where the crash reporter messages are displayed. Something similar for the network tickling tests should also be possible. Skip

On 12 May 2015, at 18:14, Tal Einat wrote:

On Tue, May 12, 2015 at 4:14 PM, Skip Montanaro wrote:

...

...

Twice now, I've gotten this popup: ...

Let me improve my request, as it seems there is some confusion about what I want. I'm specifically not asking that the popups not be displayed. I don't mind dismissing them. When they appear, I would, however, like to glance over at the stream of messages emitted by the test runner and see a message about it being expected. It seems that the tests which can trigger the crash reporter do this.

In my case, the popups appear but then disappear within a fraction of a second, and this happens about 10-20 times when running the full test suite. So I don't have a chance to interact with the popups, and this causes test failures.

Also, when running a large suite of tests, I may not be looking at the screen by the time these popups appear. I wouldn't want the tests to fail nor would I want the test run to stall.

I can't test this right now, but does disabling the "network" resource avoid these popups? Though even if it does we'll still need a way to run network-related tests on OSX.

The only way I know to easily avoid these pop-ups is to turn off the local firewall while testing. Signing the interpreter likely also works, but probably only when using a paid developer certificate. Ronald