Codesigning some (not all) apps fails

Targets macOS
1

Xojo2025r3.1

I’m getting the following error when codesigning the apps (desktop):

codesign -d -vvvv <app_path>
unsealed contents present in the bundle root

To confirm this problem:

spctl -a -vv <app_path>
a sealed resource is missing or invalid

Codesigning works fine for all the app’s libs / frameworks, it only fails on the app itself. I know my Apple certificates are all fine, because many other apps get signed with no problems. There is something about these particular apps that stop the codesigning from working, the error message is however pretty useless as it does not tell me exactly what the problem is.

I tried the following:

  • remove all resorce forks from all files
  • remove quarantine if it exists on any file

This changed nothing.

I can’t issue updates for these particular apps until this problem is solved. I never had this problem before, Apple changed something, who knows what.

Any help?

Thank you.

2

Did you code sign any included helper app, frameworks and dylibs before signing the app?
You have to sign from inside to outside.

And maybe beforehand run xattr -cr path on the folder to remove stuff.
Also good to find and delete .DS_Store files.

And this can’t be in a folder inside iCloud, Dropbox or similar.

3

I did look there first. All the plugins and the Xojo framework are signed first. One of the apps has a couple of additional dylibs which get copied over in the Build script, which are also signed before the app. But I have one app which has no additional libraries and it still fails.

Okay, I added that.

Thanks, I don’t use any of those kinds of services. I always work with data on the internal SSD.

Unfortunately, the result is the same. It doesn’t work.

I forgot to mention that my machine is a Mac Studio M1. I’ve read reports of the file system having issues with Unicode, so I checked for any unusual characters in filenames. There are none as far as I can tell.

4

Is there something in the bundle next to the Contents directory?

Also, check for symlinks that point to something outside the bundle.

5

No, the directory structure is completeley normal as far as I can see.

Thanks, I’ll do that for the one app that is using added dylibs. If they are using @rpath they should be fine, right?

What I really don’t get is that these same apps signed and uploaded with no problem to the Mac App Store. It’s only trying to sign them for use outside the app store that the signing fails. That would suggest that the certificate is at fault, but why then would many other apps sign with no problem? [ EDIT: here I mean signing with correct certificates for distribution outside MAS ] It doesn’t make any sense.

It may be that there are multiple causes, but symlinks can’t be the cause for the app that has no added dylibs but also fails. I found some text files with no extension which appeared in Finder as Unix Executable files (even though terminal told me they were identified as HTML files). I added extensions to those so they appear in Finder correctly, but that changed nothing, the signing still failed the same way.

6

You know that you have to use a different certificate in this case, right?

7

Yes. I’m using the correct certificates. They work for other apps that I also prepare for distribution outside MAS. I updated the above to try to make that more clear, thanks.

1 Like
8

Still no luck. The offending file(s) aren’t listed in the error report and I don’t see anything wrong.

9

  1. Look through your app bundle (right click app, choose Show Package Contents ) In the Mac Finder window, type Command-Shift-Period which will turn on showing of invisible files.
    Does anything look weird? The App bundle typically should have only a Contents folder at the top level.

  2. are you transferring these files to another Mac? Many file sharing services will mangle mac executables, so you need to transfer the Zip file and un-zip on the destination mac, or create a DMG…

10

Thanks, I’ve done all that. Nothing out of the ordinary.

I’ve read online reports of this problem, where certain image or icon files seem to be the cause. Of course, there’s nothing about why that would be, or what the problem actually is, just random reports from users that after they replace a certain file, then it works. I’ve had no such luck.

11

Just a blind shot… maybe some of the files have the quarentined attribute set?

12

Thanks, it’s the right idea but as I mentioned above, I checked for that already and removed all quarantines. In one case there were in fact quarantined files, but after removing quarantine from those files, nothing changed.

13

Just a thought…Apple has been threatening to remove the -d or —deep option for years. Have you tried manually signing the package from the inside out without the -d option?

1 Like
14

Oh you know what? Open the bundle in Finder and press CMD-SHIFT-.

Maybe there’s some invisible files in there?

15

I would suggest trying the “control group” test of seeing if App Wrapper can handle it.

Even if App Wrapper isn’t going to be part of the automation in the end, we’ll get the data point of “does anyone know how to get this signed”.

2 Likes
16

Thanks for the suggestion. I’ve never used it but found the free trial. Very good of Sam to allow 14 days of free use. It was easy to figure out how to use. Nicely done.

And the result is: it works. At least for the first app I tried which has consistently failed until now. App Wrapper had no trouble signing and notarizing.

Which is great, although I’m still left looking for a reason for the failure …

17

Sam’s engine signs everything from the inside out, so the -deep option could be the culprit. It is also significantly better at cleaning up (or skipping? idk) the files Apple complains about as “detritus” files. Those are those files that you read about where someone replacing the file suddenly works. (which can sometimes be the invisible Icon? file inside folders with custom icons)

18

Thanks for the suggestion, sorry I forgot to reply to this. Removing the –deep option didn’t change anything.

This appears to be one of those cases where the error message is probably just incorrect, meaning: there is a problem somewhere, but it has nothing to do with “unsealed contents present in the bundle root”, it’s something else that trips up some sequence of operations, who knows what, and the only thing that gets spit out is a failure message which is worse than useless since it has nothing to do with the real cause. That’s my guess anyway.

19

Here’s something weird App Wrapper shows me which I suppose could be a clue:

App Wrapper lists an expired “Apple Worldwide Developer Relations Certification Authority” certificate on my system, one that expired 3 years ago. The thing is, when I look for this certificate in the Keychain, it’s nowhere to be found. Nowhere. I have the current same-named certificate installed, which expires in 2030. I have no expired certificates anywhere on my system…

Except this one, apparently, somewhere … the question is: where is it? App Wrapper says it’s in “System”, but it isn’t there.

20

Have a look in your project folder, this certificate was - if I remember correctly - used in the MAS functions to verify receipts and therefor included in the project…

1 Like