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?

score 11 · Answer 1 · answered Sep 20 '14 at 15:50

11

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.

answered Sep 20 '14 at 15:50

codingFriend1

6,487
6
45
67

3

Thanks for your solution. After deleting the version.txt everything works fine – user8675 Oct 05 '14 at 17:11

score 11 · Accepted Answer · answered Sep 24 '14 at 11:25

11

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.

answered Sep 24 '14 at 11:25

Parag Bafna

22,812
8
71
144

3

The second link you gave is about frameworks. What about applications? – Thomas S. Nov 25 '14 at 10:27
This is weird, b/c I'm getting this error _when I'm trying to code sign XCode 10_. See [here](https://github.com/XVimProject/XVim2/issues/187) – abbood Sep 19 '18 at 03:33

score 8 · Answer 3 · answered Dec 13 '14 at 21:39

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.

score 2 · Answer 4 · answered Sep 26 '14 at 20:51

2

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...

answered Sep 26 '14 at 20:51

Sonic84

931
1
10
16

5

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 will reveal the folder that it is rejecting. – Will Sep 29 '14 at 19:35

score 1 · Answer 5 · answered Nov 18 '15 at 13:08

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.

score 1 · Answer 6 · answered Aug 31 '16 at 08:17

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.

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." — Phill Apley, Apr 25 '18 at 19:27
@Phill-Apley My codesign has the --force option. It was insufficient. — Peter N Lewis, Apr 26 '18 at 02:25

score 1 · Answer 7 · answered Jun 22 '17 at 01:07

1

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.

answered Jun 22 '17 at 01:07

Ken Aspeslagh

11,484
2
36
42

yoAlex5 · Answer 8 · 2021-05-03T09:39:59.463

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

score 0 · Answer 9 · answered Sep 24 '16 at 00:01

0

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.

answered Sep 24 '16 at 00:01

André Fratelli

5,920
7
46
87

score 0 · Answer 10 · answered Mar 01 '18 at 06:25

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.

score 0 · Answer 11 · answered Mar 15 '18 at 00:17

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.

Codesign: What are unsealed contents?

11 Answers11

Linked