Networking to/from application locked to 127.0.0.1

Still can't make it work outside the system. Guidance on what is required to proceed requested.

If you include a quote from another thread, it helps if you include a link to that thread for context. Here it is, just for the record.

Based on that, I’m gonna presume that you’re working on the Mac. What networking API are you using?

Also, is the affected program sandboxed?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Noted.

This is a Java 11 application using java.net.* classes at the socket level for one protocol, and Apache Mina for sftp. The communications code has been working in production for years.

How does one detect sandboxing? It fails because of 127.0.0.1 both in the IDE debugger and when installed. In the debugger it's running from .class files - would not think that would be sandboxed, unless the entire IDE is.

Why is macOS doing this? What is the logic?

How do I get past these issues that are not a problem with other operating systems? Have been working to determine whether an Apple implementation is viable. These things are quite discouraging and certainly make that difficult.

Is this a matter of an Apple Developer ID, signing certificate, or other Apple policy or procedure that I need to perform so the IDE and my software are able to operate normally?? Was hoping to release a Beta of my version 4.0 yet this year.

One last question: Does Apple evaluate (Open Source) applications to decide whether to allow them to be run? That is, if I sign-up, pay the fee and follow Apple procedures can it potentially be blocked? Is there anything written about how those decisions are made?? I'm sure you can understand not wanting to waste further time, effort or money.

Once again, thank you for your time.

Details:

• hostname returns correct name
• host using that name returns the correct IP address
• ping from another system using the name works - so that IP is being used by macOS

However:

• Configuration of my software uses that IP address, not name
• Software in listener mode is forced to 127.0.0.1
• Happens when installed and when executed from .class files in the IDE debugger

What's the prescribed combination to make it work?

This is the weirdest behavior I've ever seen in networking since I wrote assembly language device drivers for Intel Ethernet cards and developed software for Cisco switches.

Have gotten passed that 127.0.0.1 problem. Added the .app to Firewall Options.

Now encountering the "Do you want the application to accept incoming network connections?" - every time it's run.

Tried: codesign --force --deep --sign - /Applications/the.app but it still appears.

Because I'm behind my own custom firewall have disabled the on-box firewall for now.

Now this, from what I've read, does involve proper code signing. Is that correct?

Have gotten passed that 127.0.0.1 problem. Added the .app to Firewall Options.

Cool.

Now encountering the "Do you want the application to accept incoming network connections?" - every time it's run.

Tried: codesign --force --deep --sign - /Applications/the.app but it still appears.

Right. There are two problems here:

• It’s using --deep, which I recommend against. See --deep Considered Harmful.

• It’s using an ad hoc signature. That won’t help the firewall issue because the firewall needs a stable code signing identity to confirm that version N+1 of your app is the ‘same code’ as version N.

I recommend that you sign your code properly, per the rules in Creating Distribution-Signed Code for Mac. For day-to-day development, using a development signing identity (Apple Development: TTT). For distribution, see the Confirm Your Code Signing Identity section of that post.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

After investing a good bit of money in a Mac and spending weeks getting my eight-year old application to look and behave like a "real" Mac app I have decided to back-burner the idea of supporting macOS.

Thanks for those links. Guess I should have spent time investigating Apple's policies and procedures before delving into this. Had assumed it was a straight-forward proposition but I was woefully wrong. At this point I would have to rework my updater - that works everywhere else - because of Apple's procedures. And then pay to proceed.

Correct me if I'm wrong but, from reading here and on other forums it seems that even after going through it all there is no guarantee my application would be "allowed". Apple reviews and evaluates applications before notarizing the required certificate. If Apple doesn't like the app for whatever reason they can deny it.

Is that correct?

Thanks again for your time.

As I mentioned early-on in our discussions I have a Macbook Pro 13" Retina Late 2013. 2.8 GHz running Big Sur and added a Thundebolt dock and other goodies.

Just read that Apple obsoleted the signing tools on 1 Nov 2023. The new tools require Monterey ... that is not supported on this Macbook Pro due to Apple's unethical forced obsolescence of hardware.

I started this endeavor right when the tools were obsoleted. So I've wasted a lot of money and almost 2 months of work for NOTHING.

I have absolutely NO intention of buying a new computer to give away software because of Apple's sheer greed.

Sure wish you would have said something a few weeks ago.

I will be deleting this developer account in a few days and attempting to sell this piece of shit. Will never have anything to do with Apple crap ever again, and will make sure my children, grandchildren, friends and anybody I talk to never touch any locked-in, Big Brother, planned obsolescence utter garbage from your company. EVER!

Sorry for wasting your time. Apple doesn't deserve you.

Correct me if I'm wrong but, from reading here and on other forums it seems that even after going through it all there is no guarantee my application would be "allowed". Apple reviews and evaluates applications before notarizing the required certificate. If Apple doesn't like the app for whatever reason they can deny it.

The Mac supports two distribution channels:

• Mac App Store

• Direct distribution using Developer ID

The former involves App Review, who enforce the App Store Review Guidelines. The latter requires notarisation. These are very different processes. To quote Notarizing macOS software before distribution:

Notarization gives users more confidence that the Developer ID-signed software you distribute has been checked by Apple for malicious components. Notarization is not App Review. The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues, and returns the results to you quickly.

My experience is that the notary service rejects a product for one of three reasons:

• The product contains malware.

• The product is constructed in a way that prevents the notary service from checking it for malware.

• Something is borked with the notary service )-: This is rare, but it does happen. Obviously we strive to fix such problems promptly.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you for the explanation. That clears-up some of my misunderstanding.

After calming-down decided to rearrange the code and create a basic Linux .tar.gz with an embedded JRE for macOS. That will allow older Macs to use the software without building the project themselves, which will always work.

IF enough users want a DMG so it can be installed on newer Macs, and donate the necessary funds or hardware, I may come back to this. And discovered another potential approach of using an Amazon EC2 Mac instance to build and test ELS on the latest macOS. Developing on this old Macbook Pro, then building on EC2 might keep it within their "free tier".

Other than the certificate and DMG it looks and behaves like a real Mac app ... the Corionis ELS project: https://corionis.github.io/ELS