Internet Commands keep my Mac app from Notarizing

I’ve just about got my Mac app notarized except the internet command bundle returns a notarization error: “The binary uses an SDK older than the 10.9 SDK”.

I would really like to get the app notarized ASAP so I hope 4D is hard at work getting the Internet Commands to the point where the notarization process will accept them.

Scott

Somehow I get the feeling that 4D plans to replace Internet Commands with some more modern reentrant code.

…i meant preemptive not reentrant…

You are posting on the 4D V17 corner is this right ?

As for now only 4D v17 R5 will be compliant for notarization

So… with which version have you tested ?

I am using 17.1.

I noticed the later R versions of 17 are comparable with Xcode 10.x. However, I will be distributing my software for sale over the internet and am reluctant to use an R version for that. What I am hoping is that 17.2 will have updated internet commands and whatever else that’s needed and can be notarized. It would be unreasonable for 4D to make us wait for version 18 to have a production version that enables notarization.

Version 17.2 came out and I submitted the app built with 17.2 to be notarized by Apple. Unfortunately the app still does not notarize. There are only 2 errors now, both due to “The binary uses an SDK older than the 10.9 SDK.” in reference to the Internet Commands bundle.

I’m very disappointed. This situation represents a serious shortcoming in 4D ability to provide up-to-date software to its customers. Xcode 8.x (or earlier) hasn’t been current since September 2017.

I was also hoping v17.2 would work with notarization. With v17R5 not certified for Windows 7/8 on one hand, and yet being required for notarization on the other hand, leaves me in a bit of a predicament until I can get everyone to move to Windows 10 which will take longer than it will for someone to move to macOS Catalina. :frowning:

4D v17.x line will continue to provide compatibility with 32-Bit versions. Or in other words: we do not plan to stop 32 Bit support with the 4D v17.x line.

On the other side, 4D v17 R5 completely cuts 32-Bit support, read: https://blog.4d.com/64-bit-support-brings-new-opportunities/

This cut is required to be fully compatible with 10.5/Catalin (while v17.x will work with some restrictions).

Regarding Windows 7: please note that Microsoft announced many years ago the end of Windows 7 for January 2020, similar as with Windows XP some years ago. Don’t miss to push your customers to move now, not to wait as last time till the very end. The risk is extremely high that there will be heavy attack waves running with so far unknown exploits as soon Microsoft stops to fix security issues.

That’s the reason why we stop certifying Windows 7 now. It does not mean it will stop working, we changed nothing in the code, just we do not run through all the manual tests anymore.
As Windows 7 shares code base with Windows Server 2012, which we still support as Terminal Server, we don’t expect issues. But as written, we don’t test anymore and will not fix Windows 7 specific issues any longer, which do not occur on Windows Server 2012 as well.

Hi Thomas,

Certainly we are trying to move customers to Windows 10 as quickly as possible. From what you’ve said, it’s not clear to me whether the 64-bit versions of v17.x can be notarized. We’re 100% 64-bit now so that would solve this issue if that makes a difference. Do you know if that is the case?

Thanks.

: Cannon SMITH

From what you’ve said, it’s not clear to me whether the 64-bit
versions of v17.x can be notarized.

There are no “64-bit” versions of 4D IC for Mac for v17.x…
These are “fat-bundles”, containing both 32 and 64 bit binaries
4D v17 R5 only contains 64-bit, there is no 32-bit included anymore, that’s a major difference.

As of today - as far as I know - this blocks notarizing for 10.15. But this might change in the coming weeks. Apple might change or we might find another solution, cannot say yet.
As of today, we know that it will work with R5, we did not detected something (so far) requiring more drastical modifications, but you might remember 10.14 - Apple changed ‘something’ 2 weeks before shipment. We was quite ready with certifications and that late change required us several months of redevelopment. Months, not days. I’m sorry to say so, but looking on history we cannot give any statement before Apple shipped the final version.

Thank you, Thomas. It is clear to me now.

Speaking of notarization, I just watched the 2019 WWDC session on notarization. I thought the only change from what was announced last year would be that Catalina would require notarization. Nope, there are other changes as well.

For example, it is now required to opt in to the Hardened Runtime capability. Also, if I understood right (this part was fuzzy to me), in the hardened runtime an app will not run if anything in the app bundle changes during runtime which I believe 4D still does.

For those of us using codesign with the --deep parameter, this shortcut may stop working. If so, we’ll have to manually sign each part of the bundle from the inside out.

There were lots of other things that were covered and I’m not sure how much of it applies to 4D applications.

I won’t be able to test any of this until I move to at least R5, but if anyone is planning on notarizing apps they’ll probably want to watch that WWDC session. Hopefully 4D engineers are aware of all the picky details. It is getting harder to distribute applications, but that’s the world we live in now.

When you are ready to attempt notarizing your Mac app here are the terminal commands that are working for me:

xattr -cr (takes stuff out of the app that can’t be there for code signing)

codesign -vv --deep --strict --force --timestamp --option=runtime --sign “Developer ID Application: Scott Manders (XXXXXXXXXXX)”

Then make a signed (codesign -v --force --strict --timestamp --options=runtime --sign “Developer ID Application: Scott Manders (XXXXXXXXXXX)” ) dmg with this app and submit for notarization:

xcrun altool -t osx -f --primary-bundle-id com.. --notarize-app --username scottmanders@xxxxxxxx.com

This command takes a long time to complete depending on the size of the dmg that’s uploaded to Apple.

You will have to give your Apple ID password a couple times along the way.

It will not notarize — 31 errors for me — but when you go to the error log url you get when you give the below command, it will have all the paths that had an error. My errors for this first run were all due to No Timestamp, Not Runtime Hardened or Not/Not Adequately Signed; your app may be different. Note: the terminal manual for the --deep option for the codesign command says that often you have to give the command recursively to get everything in an app bundle signed; I think Xcode does this recursive signing automatically.

xcrun altool --notarization-info -u scottmanders@xxxxxxxx.com

Then you give multiple terminal commands the same as the codesign command above except you substitute the failed path names given you in the url’s webpage (copy this webpage into a separate document because it doesn’t persist long). Multiple commands can be strung together separated by “;” and “&&” without the quotes. && waits for the preceding command to complete before running the next command and ; does not wait. You can use both in the same command string. Or you can write a shell script with all the commands. I did not bother with the shell script.

That still did not notarize for me. There was one more signing error that was easily taken care of by adding to the terminal command string. However, two errors due to the internet commands bundle not being compiled against a recent enough version of Xcode I could not fix.

That was all with 17.1 and 17.2 and I got down to 2 errors as noted. I am going to try with 17R5 soon. Hopefully it will work but there may be additional errors due to the changes in 17R5 or other factors.

As per Thomas Maul’s postings above, I don’t think we can be certain everything will work right until the final version of Catalina comes out.

Good luck.

the " --force" option seems to be a “no go”
if you want to sign 4D with the hardened runtime entitlement.

in principle you’d want to start with a clean package,
with no signatures or extended finder attributes,
and sign packages from the inside out,
then finally sign the outmost package.

packages require the “–deep” option,
but you’d want to avoid using the “–deep --force” combination,
or else all the work you’ve done for its inner contents will be invalidated.

basically, only the 4D Helper app (inside the CEF framework),
helper tools, PHP and the main executable need hardened runtime,
all other plugins and frameworks just need to be signed.

in order to grant hardened runtime entitlement, you need to supply an XML plist file,
the gotcha is that a plist file is not a regular XML file, it has some specific metadata to
distinguish binary1 or xml1 format (same file extension),
so you have to convert the plist file you created using native 4D commands,
otherwise the entitlements are corrupt.

there are some other factors to consider,
but 4D Internet Commands is probably the least of your concerns.

https://miyako.github.io/2019/06/17/notarization.html

Thanks.

I’ll come back to you post when I have more troubles down the line.

Hi Miyako,

Thanks for the info.

: Keisuke MIYAKO

but 4D Internet Commands is probably the least of your concerns

That’s what I was afraid of! :slight_smile:

I downloaded 17R5 and substituted its Internet Commands Bundle for the stock one in 17.2 (17R5’s Plugin works well for the uses in my app). Using the techniques above the app Notarized.

[]30813296;“Your comment here…”[/]

I see that Apple has temporarily relaxed some of the notarization rules (https://developer.apple.com/news/?id=09032019a). Has anyone looked into how the changes affect this conversation?

Only for 4 month (until January 2020) so not a revolution… :roll: