2013-10-04 12 views
6

私はビルドにコード署名を統合しており、ソースコードツリー内に保持されているコードに署名するために使用されるカスタムキーチェーンを作成しました(~/Library/Keychains使用される前に、それはよく知られた場所にあります)。Codesignは "IDが見つかりませんでしたが、IDはキーチェーン上にあります

しかし、私はエラーを取得する署名しようとしたとき:しかし

$ /usr/bin/codesign --sign='Mac Developer: John Doe (AA1AAA1AAA)' \ 
    --keychain=~/Library/Keychains/xxx.keychain \ 
    dist/64/gmake/release/bin/libmylib.dylib 

Mac Developer: John Doe (AA1AAA1AAA): no identity found 

$ security find-identity -p codesigning ~/Library/Keychains/xxx.keychain 

Policy: Code Signing 
    Matching identities 
    1) 49F2FBE79899DF18A9638AC6B1302E2EB6E079AD "Mac Developer: John Doe (AA1AAA1AAA)" 
    1 identities found 

    Valid identities only 
    1) 49F2FBE79899DF18A9638AC6B1302E2EB6E079AD "Mac Developer: John Doe (AA1AAA1AAA)" 

codesignはアイデンティティを見つけることができない理由だから私は理解していません。

誰も解決策を提案できますか?

私はIDのSHA-1を試してみましたが、同じ結果が得られました。

答えて

8

codesignのエラーメッセージの一部が明確ではありません。ここでの問題は、codesignがキーチェーンを見つけることができず、それが--keychain=~/pathの使用に起因することです。これは単一の引数として解釈され、チルダ展開は実行されません。別々の引数を使用するようにコマンドを変更した場合、期待どおりに動作するはずです。

codesign --sign 'Mac Developer: John Doe (AA1AAA1AAA)' \ 
    --keychain ~/Library/Keychains/xxx.keychain \ 
    dist/64/gmake/release/bin/libmylib.dylib 
+0

興味深いことに、この方法で引数を指定すると、シェルが '〜'を展開しないとは考えていませんでした。私は明日テストして、あなたに戻ってきますが、あなたが勝者になったと思います。 – trojanfoe

+0

はい、これは答えですが、私は 'security unlock-keychain'でロックを解除したにもかかわらず、「ユーザーのやりとりは許可されていません」となっています。今私はシーケンスが 'login.keychain'で動作することを知っています(私はそれを頻繁に行います)。しかし、非標準のキーチェーンを使用すると動作しないようです。私は*助け吸血鬼*であることは嫌いですが、何か提案はありますか? – trojanfoe

+0

私はカップルの可能性を考えることができます。 1つは、システムがユーザーにアクセスを許可するようにするために、キーチェーンが秘密鍵へのcodesignアクセスを常に許可するように構成されていないことです。秘密鍵をダブルクリックし、アクセス制御の下にcodesignを追加する(またはすべてのアプリケーションを許可する)ことにより、Keychain Access経由で設定することができます。もう1つは、ビルドプロセスの早い段階でロック解除が発生すると、デフォルトのキーチェーンロック解除タイムアウトが5分になりすぎることです。キーチェーンの設定でこれを制御して、タイムアウトを延長または削除することができます。 –

関連する問題