Codesign: What are unsealed contents?

Question

I have just upgraded to XCode 6 and tried to build my Developer ID signed Mac app. However, I now get the following codesign error:

unsealed contents present in the root directory of an embedded framework

This applies to the Dropbox.framework that I use. Obviously that could not be signed. What does the error mean? What is wrong?

Quintus

Answer 1

Have a look at OS X Code Signing In Depth

Beginning with OS X version 10.9.5, there will be changes in how OS X recognizes signed apps

Structure your bundle according to the expectations for OS X version 10.9 or later:

• Only include signed code in directories that should contain signed code.
• Only include resources in directories that should contain
  resources.
• Do not use the --resource-rules flag or ResourceRules.plist. They have been obsoleted and will be rejected.

Medford

The second link you gave is about frameworks. What about applications? – Abattoir

This is weird, b/c I'm getting this error when I'm trying to code sign XCode 10. See here – Nichy

Answer 2

The problem is the version.txt file that resides in the Dropbox.framework. While this is useful to know which version the framework is, it seems no longer to be OK for codesigning.

When I removed the file everything worked fine again.

Quintus

Thanks for your solution. After deleting the version.txt everything works fine – Subir

Answer 3

Had the same problem for several hours today, as I tried to adapt a pre-Yosemite .framework bundle to Yosemite. In the end, the problem was the symlinks I made, not strictly files in the directory.

Initially, the package had a broken symlink in its root directory. I fixed it up.

The symlink I added:

Headers -> Versions/Current/Headers/

What it needed to be:

Headers -> Versions/Current/Headers

That extra slash is the killer.

Note that this bit me twice in two different spots: I also had

Current -> 1.8.0/

where I needed

Current -> 1.8.0

I'm not much of a *nixer, so maybe this is common sense, but hopefully it helps other windows devs like myself.

Cybele

Answer 4

I ran into a similar issue today... my error was "unsealed contents present in the bundle root". The fix for me was to remove the custom icon I had on on my app. AppName.app/Icon? was corrupt somehow...

Jura

Or perhaps it was in a directory that should not contain resources. The tech note referenced above states this about the allowed locations for code within a bundle These places are expected to contain only code. Putting arbitrary data files there will cause them to be rejected. Codesign -vvv <yourapp> will reveal the folder that it is rejecting. – Waldenburg

Answer 5

I researched this for a while today and none of the suggestions I found helped, my sdl_mixer.framework had five embedded frameworks that I couldn't get past iTunesConnect. My solutions was to remove three of them that I didn't actually need, and the other two were added to my project as standalone frameworks, not embedded in the sdl_mixer. Hopefully this helps someone, I spent hours on this.

Zehe

Answer 6

I have hit this twice now, so I am adding the causes, since codesign is very opaque and generally refuses to tell you what the problematic resource is.

On one occasion, I had an unsigned binary executable. Each executable and framework needs to be individually signed before singing the bundle as a whole.

Then I hit another case. I sign my code as part of the publish process, re-signing each executable and framework. But Xcode also signs the bundle as well, and it turns out that was leaving cruft behind in _CodeSignature folders. So now, before signing each of the executables and frameworks and then the bundle, I pre-remove Xcode's generated _CodeSignature folders with something like:

find MyApp.app -name _CodeSignature -type d -exec rm -rf {} +

Hopefully this hard-won information will save someone some time one day.

Haitian

The -f option to codesign is supposed to replace all the old signatures. From the man page: " -f, --force When signing, causes codesign to replace any existing signature on the path(s) given. Without this option, existing signatures will not be replaced, and the signing operation fails." – Featherbedding

@Phill-Apley My codesign has the --force option. It was insufficient. – Haitian

Answer 7

In my case, I was trying to sign an app with some old frameworks inside. None of these suggestions helped. Turned out I had to remove the PkgInfo file from inside a framework to get this message to go away.

Culmination

Answer 8

I had such error:

<some_path>: unsealed contents present in the bundle root
Command CodeSign failed with a nonzero exit code

The issue was that I used a custom CONFIGURATION_BUILD_DIR^[About]. And after some changes(changing macOS and iOS platforms) it occurred

And when you clean your project this custom location build is not cleaned(like derived data). To solve this problem remove content of this folder manually

Nineteenth

Answer 9

I had the same problem and what worked for was deleting the contents of the DerivedData folder. Xcode doesn't say which resource is causing the problem, so I rebuilt everything from scratch. Clean didn't work either.

Spondaic

Answer 10

I hit the problem when I tried to sign another framework, the answers here are very inspiring, here must be some problems with the framework structure, but I did find any them. The structure seems to be right, the symlinks have not tailling "/", there is not extra file (checking with ls) ...

After tons of trying, I finally realized there is a extra .DS_Store in the framework, which is really annoying :(

So if you still hit the error, try to check if there is any hidden files.

Originality

Answer 11

Another possible cause of this problem: if you are building iOS and macOS apps that have the same name and the same installed location, you may find that both of them are written into the same app bundle. First the iOS app build places its contents directly in the app bundle root, and then the macOS app build places its contents into a "Contents" folder in the app bundle, and then codesign complains about the iOS resources.

Disturbed