“codesign”

I got both issues with a fresh new certificate, so it was not just about the certificate being old.But I got around it by specifying the certificate by ID instead of name — first getting the ID via:security find-identity -p codesigningand, from the output of that, copying the long hex ID for the key I want, and pasting that into my codesign invocation:sudo codesign -s 001CA54450805B2D8D1646793D0339BA7EB931D1 --timestamp=none /opt/local/bin/ggdb

Oh I am also using 3rd Party Mac Developer Application:when codesigning since I am trying to distribute to the app stroe

Yep, same problem here with macOS Sierra and Xcode 8.2.1 and submitting an app to the Mac App Store.Funny thing is, previous verions of the app, 1.0, 1.0.1, and 1.0.2 submission worked okay. Nothing has changed as far as entitlements, or code signing, or provisioning profiles. And yet, I am unable to submit 1.0.3 of my app. It gives me the unhlepful Invalid Binary message. And in one email:App sandbox not enabled - The following executables must include the com.apple.security.app-sandbox entitlement with a Boolean value of true in the entitlements property list. Refer to the App Sandbox page for more information on sandboxing your app.Which wasn't true, as the codesign command-line utility showed that the binary had the app-sandbox entitlement set to true.I even went as far as revoking all previous certificates, and deleting all provisioning profiles, and regenerating from scratch. And turning off Xcode's automatic management of code-signing and ensuring release builds are using the production codesigning

Yep, same problem here with macOS Sierra and Xcode 8.2.1 and submitting an app to the Mac App Store.Funny thing is, previous versions of the app, 1.0, 1.0.1, and 1.0.2 submission worked okay. Nothing has changed as far as entitlements, or code signing, or provisioning profiles. And yet, I am unable to submit 1.0.3 of my app. It gives me the unhlepful Invalid Binary message. And in one email:App sandbox not enabled - The following executables must include the com.apple.security.app-sandbox entitlement with a Boolean value of true in the entitlements property list. Refer to the App Sandbox page for more information on sandboxing your app.Which wasn't true, as the codesign command-line utility showed that the binary had the app-sandbox entitlement set to true.I even went as far as revoking all previous certificates, and deleting all provisioning profiles, and regenerating from scratch. And turning off Xcode's automatic management of code-signing and ensuring release builds are using the production codesigning

Yep, same problem here with macOS Sierra and Xcode 8.2.1 and submitting an app to the Mac App Store.Funny thing is, previous versions of the app, 1.0, 1.0.1, and 1.0.2 submission worked okay. Nothing has changed as far as entitlements, or code signing, or provisioning profiles. And yet, I am unable to submit 1.0.3 of my app. It gives me the unhelpful Invalid Binary message. And in one email:App sandbox not enabled - The following executables must include the com.apple.security.app-sandbox entitlement with a Boolean value of true in the entitlements property list. Refer to the App Sandbox page for more information on sandboxing your app.Which wasn't true, as the codesign command-line utility showed that the binary had the app-sandbox entitlement set to true.I even went as far as revoking all previous certificates, and deleting all provisioning profiles, and regenerating from scratch. And turning off Xcode's automatic management of code-signing and ensuring release builds are using the production codesigning

I'm also getting this same issue since yesterday - when I try to export using my Developer ID, I get an error message saying that there has been a codesign error and offering to show the logs. The logs show the same message, but seem to relate to code-signing Autoupdate.app inside the Sparkle framework, which my app uses for updates when distributed outside the App Store:2017-01-13 14:56:12 +0000 Disqualifying <DVTSigningCertificate: 0x7fdd64e0d600; name='Mac Developer: DevName', hash='HASH', serialNumber='SERIAL', certificateKind='1.2.840.113635.100.6.1.12, issueDate='2016-09-27 14:31:07 +0000''> due to certificateKind (input 1.2.840.113635.100.6.1.13 doesn't match 1.2.840.113635.100.6.1.12)Has anyone figured out how to fix this yet?Edit: Argh, I found the problem and it was something stupidly simple. A couple of days ago I changed my system clock to test a time-based feature, and although I'd change it back to show the right time, somehow it wasn't set to Set date and time automatically. The

Maybe I come too late but I was looking for the same answers and I found a sane recommendation in the Carthage wiki:If the embedded framework in your project has dependencies to other frameworks you must link them to application target (even if application target does not have dependency to that frameworks and never uses them).This actually makes some sense to avoid conflicts in case if the developer of the app decides to link to FC not knowing that FB already uses FC, and maybe even another version of it.And also I found an official note here:https://developer.apple.com/library/content/technotes/tn2435/_index.htmlsaying one important thing:The app target is responsible for embedding all of the frameworks, including any frameworks that other frameworks depend on.See the section Apps with Dependencies Between Frameworks for full instructions. This means, if your framework B depends on framework C, you are forced to link FC to FB and FB to A anyway just to be able to build your project, but at the end you shoul

It sounds like your app was built with the wrong entitlements. If you do the following (make sure to target the app as its downloaded from the store), what do you see:$ codesign -d --entitlements :- /Applications/Your.appShare and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com