I just updated my Mac to Mac OS X Sierra and am still using Xojo 2014 release 3.2. A program that built perfectly yesterday with code signing in El Capitan now gives the following code signing error:
/Users/…: resource fork, Finder information, or similar detritus not allowed
Any suggestions?
Maybe clear the extended attributes before codesigning. Something like xattr -c -r ./your.app
Also, RB App Checker Lite often helps me in these cases. Just drop in your App and see what it complains about.
Thanks for your suggestion. I did run it through RB App Checker Lite and found one file (an old PNG) with a legacy resource fork. I’ve replaced that file and done another build but the error persists.
Sam has released an update of App Wrapper for Sierra. Downloading just now.
That solved the problem. I had been using App Wrapper Mini. Tried App Wrapper 3.6.1 and same problem but just downloaded v. 3.6.2 and the build now works without a code signing error.
It’s not because of macOS Sierra - it’s because of the CodeSign utility that comes with Xcode 8.
So Marco’s answer is “correct” 
You currently still can CodeSign with the previous version of Xcode (and you won’t get the “resource fork, Finder information, or similar detritus not allowed” error).
Or you can clean up your built app before CodeSigning:
# Removing extended Attributes (otherwise Xcode 8 won't sign)
xattr -rc /Path/to/your.app
Here’s a Post Build Script example of mine which does both CodeSign and create a signed DMG (without using any 3rd party utilities, but obviously Xcode utilities are needed).
[quote=288030:@Jürg Otter]It’s not because of macOS Sierra - it’s because of the CodeSign utility that comes with Xcode 8.
So Marco’s answer is “correct” :-)[/quote]
Didn’t mean to imply that his answer was incorrect, just that the update to the wrapping utility that I used fixed the problem for me. For what it’s worth, I have not upgraded Xcode to v. 8; I still have v. 7.3 installed but there may well be components of Xcode that get updated with a system upgrade that I’m not aware of.
Thanks for sharing your utility!
The latest version of App Wrapper does indeed solve this issue, and various others related to code signing on Sierra.
http://ohanaware.com/whatsNew/?pageName=appWrapper.html
This version had a length beta period in order to catch as many issues as possible before Sierra was released.
Sam, could you explain what did cause the 10.12 issue the OP had? I like to know if my own signing scripts (not using your tool) might also be affected by something. As you may remember, my Find Any File, for instance, built and signed over a year ago, has resource forks, EAs and even PPC code in the bundle, yet I saw no issues with that on Sierra.
Thomas,
Sure thing, I’ll PM you with a list of things that it does which seems to have solved this issue for many users.
I’m still getting this issue in App Wrapper 3.6.3 (191). Is there a later/beta release I should be using?
Tom you’re the second person in two days that’s reporting this. Are you running the 10.12.1 beta?
I’ve made some more changes and App Wrapper 3.6.4 now cleans even more potential crap that Apple likes to automatically add to your application, which it’s own code sign utility doesn’t like.
http://www.ohanaware.com/appwrapper/appWrapper3update364Beta.dmg
On an optimistic note, 3.6.3 has fixed my issues
Sam didn’t mentioned it but it is also not possible anymore to have a hidden file in the .app resources. This will always result in a faling code signing (resource fork, Finder information, or similar detritus not allowed)
Sam has added some checking for this in 364beta and that fixes the issue.
The forbidden hidden files have been around for a while I think. Anyway, if one absolutely wants a hidden file, it is pretty simple to compress it, and extract in AppData.
Yes, but when running Sierra, you cannot codesign your app anymore if they are present in the .app content. With all previous OSX versions it didn’t matter.
My point is that Apple said not to put any in the bundle. Now probably because people would not listen, they enforced it by software.
I see why some paranoid personalities may want to hide files for them not be peaked at, but indeed, an encrypted zip will do the trick in a more secure and elegant way.
I cannot code sign at all on Sierra even with the new update I got on App Wrapper today. Its complaining with that same complaint old Style resource fork and finder attributes.
Doesn’t the newest AppWrapper clean that up for you?