Xcode 4.6.3 中 Dropbox API 的编码失败:“代码对象根本没有签名" [英] Codesign of Dropbox API fails in Xcode 4.6.3: "code object is not signed at all"

查看:21
本文介绍了Xcode 4.6.3 中 Dropbox API 的编码失败:“代码对象根本没有签名"的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个通过 Mac App Store 分发的 OS X 应用程序,最近更新到 Xcode 4.6.3.

I have an OS X app that's distributed through the Mac App Store, and recently updated to Xcode 4.6.3.

当我现在运行我的常规构建时,我收到:

When I run my regular build now, I receive:

Command /usr/bin/codesign failed with exit code 1:

/Users/Craig/Library/Developer/Xcode/DerivedData/Mac-dxcgahgplwpbjedqnembegifbowj/Build/Products/Debug/MyApp.app: code object is not signed at all
In subcomponent: /Users/Craig/Library/Developer/Xcode/DerivedData/Mac-dxcgahgplwpbjedqnembegifbowj/Build/Products/Debug/MyApp.app/Contents/Frameworks/DropboxOSX.framework
Command /usr/bin/codesign failed with exit code 1

我似乎无法辨别项目中的任何其他更改,因此我无法确定这是与 4.6.3 更新相关的问题还是其他问题.

I can't seem to discern any other changes in my project, so I can't tell if it's an issue related to the 4.6.3 update, or something else.

我尝试重新启动 Xcode,运行干净的构建,并清理构建文件夹.

I have tried restarting Xcode, running a clean build, and cleaning the build folder.

推荐答案

我想我可能已经想通了.我一直在 OS X Mavericks 上运行 Xcode 4.6.3,给人的印象是任何特定于构建的工具都捆绑在 Xcode 应用程序中.

I think I may have figured this one out. I've been running Xcode 4.6.3 on OS X Mavericks, under the impression that any build-specific tools were bundled in the Xcode application.

但是,似乎code>codesign/usr/bin 中.我不确定它是由 Xcode 安装程序之一放置的,还是带有 vanilla 系统安装的,我不确定.但是阅读codesignman页面,我发现了这个漂亮的选项:

But, it seems codesign is in /usr/bin. Whether it's put there by one of the Xcode installers or comes with a vanilla system install, I'm not sure. But reading through the man page for codesign, I found this nifty option:

--deep  When signing a bundle, specifies that nested code content such as helpers, frameworks, and plug-ins, should be recursively signed
             in turn. Beware that all signing options you specify will apply, in turn, to such nested content.
             When verifying a bundle, specifies that any nested code content will be recursively verified as to its full content. By default,
             verification of nested content is limited to a shallow investigation that may not detect changes to the nested code.
             When displaying a signature, specifies that a list of directly nested code should be written to the display output. This lists only
             code directly nested within the subject; anything nested indirectly will require recursive application of the codesign command.

然后我发现了这个帖子 (https://alpha.app.net/isaiah/post/6774960) 两周前(~2013 年 6 月),其中提到(尽管是二手的):

And then I found this post (https://alpha.app.net/isaiah/post/6774960) from two weeks ago (~June 2013), which mentions (albeit second-handedly):

@isaiah 我问过实验室里的一个人.他说现在协同设计需要在代码之前单独签署嵌入式框架对整个应用程序包进行签名.

@isaiah I asked a guy in the labs about it. He said codesign now requires embedded frameworks to be signed separately before code signing the app bundle as a whole.

手动重新运行 Xcode 正常运行的 codesign 命令,同时在末尾添加 --deep 标志,正确签署应用程序.

Manually re-running the codesign command that Xcode normally runs, while adding the --deep flag to the end, signs the application properly.

我还不确定这个手动签名到底有什么后果,或者我是否可以调整 Xcode 构建以自动添加 --deep 标志,但这似乎是潜在的问题.(codesign 不再自动对您的 app bundle 进行深度签名.)

I'm not yet sure exactly what ramifications this manual signing has, or whether I can tweak the Xcode build to add the --deep flag automatically, but this seems to be the underlying issue. (codesign no longer automatically deeply signs your app bundle.)

这篇关于Xcode 4.6.3 中 Dropbox API 的编码失败:“代码对象根本没有签名"的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆