Nossa compilação automatizada está sendo executada no Jenkins. A construção em si está sendo executada em escravos, com os escravos sendo executados via SSH.

Eu recebo um erro:

00:03:25.113 [codesign-app] build/App.app: User interaction is not allowed.

Eu tentei todas as sugestões que vi até agora em outros posts aqui:

• Usando a segurança unlock-keychain imediatamente antes de assinar para desbloquear o keychain.
• Movendo a chave de assinatura para seu próprio chaveiro.
• Movendo a chave de assinatura para o chaveiro de login.
• Movendo a chave de assinatura para o chaveiro do sistema.
• Definir manualmente chave-de-lista apenas para o chaveiro que contém a chave.

Em todos os casos, recebo o mesmo erro.

Na tentativa de diagnosticar o problema, tentei executar o comando "security unlock-keychain" no meu terminal local e descobri que ele realmente não desbloqueia o chaveiro - se eu procurar no Keychain Access, o símbolo de bloqueio ainda está lá. Esse é o caso, se eu passo a senha na linha de comando ou deixo que ela me solicite. Desbloquear o mesmo chaveiro usando a GUI solicitará a senha e a desbloqueará. Além disso, se eu executar "segurança lock-chaveiro", eu fazer ver o bloqueio de teclado imediatamente após a execução do comando. Isso me faz pensar que as chaves de desbloqueio não funcionam realmente. Eu experimento o mesmo comportamento no Lion (que estamos usando para os escravos de construção) e no Mavericks (no qual estou desenvolvendo).

Em seguida, tentei adicionar -v a todos os comandos de segurança:

list-keychains "-d" "system" "-s" "/Users/tester/.secret/App.keychain"
Listing keychains to see if it was added: ((
        "/Library/Keychains/System.keychain"
))
unlock-keychain "-p" "**PASSWORD**" "/Users/tester/.secret/App.keychain"
build/App.app: User interaction is not allowed.

A partir disso, parece que a lista de chaveiros é o que não está funcionando. Talvez nem funcione. : /

Há uma pergunta semelhante aqui . A solução é interessante - defina "SessionCreate" como true no launchctl. Mas não estou desenvolvendo o mestre - meu processo de criação é iniciado a partir do SSH em uma máquina de criação escrava. Talvez exista uma maneira da linha de comando de fazer o que o launchctl está fazendo quando você executa "SessionCreate"?

Eu também tenho lutado contra isso. Nada ajudou até eu tentar a sugestão em http://devnet.jetbrains.com/thread/311971 . Graças agrawal ashish!

Efetue login no usuário da compilação através da GUI e abra o Acesso às Chaves. Selecione sua chave privada de assinatura, clique com o botão direito do mouse, escolha Obter informações, vá para a guia Controle de acesso e selecione "Permitir que todos os aplicativos acessem este item".

Bem, acho que posso responder minha própria pergunta hoje, porque depois de esfaqueá-la por mais de dois dias e meio, uma das coisas que tentei parece ter funcionado. Só vou me afastar agora e espero que continue funcionando.

Basicamente, parece que tudo se resume a -d systemnão funcionar. Portanto, muitas respostas para outras perguntas por aqui provavelmente devem ser atualizadas para refletir isso.

security -v list-keychains -s "$KEYCHAIN" "$HOME/Library/Keychains/login.keychain"
security list-keychains # so we can verify that it was added if it fails again
security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN"
codesign --sign "$SIGNER_IDENTITY" --force --signature-size 9600 \
         --resource-rules src/AppResourceRules.plist --timestamp --verbose \
         "$APP"

Nenhuma das outras respostas funcionou para mim.

O que acabou me salvando foi este post

Para resumir, isso pode ser causado por um tempo limite padrão de 5 minutos, que disparará esse erro após uma compilação longa.

Consertar:

security set-keychain-settings -t 3600 -l ~/Library/Keychains/login.keychain

Tente chamar security unlock-keychaine codesigncomo um comando de uma linha. Isso me ajudou. Algo como:

security unlock-keychain -p <password> /Users/<user>/Library/Keychains/login.keychain && codesign --force --verify --verbose --sign "<certificate id>" <app name>

Usando o Security para criar um Keychain para / usr / bin / codesign

Importar o certificado e fazê-lo funcionar com o design de código de forma programática não é uma questão de usar chaveiros de login ou do sistema ou rezar para algum deus do design de código. Você só precisa ter as permissões corretas definidas. Eu recomendo criar um novo chaveiro especificamente para fins de design de código.

Hoje em dia, para codesignnão gerar um, errSecInternalComponenté necessário obter a lista de partições (ACLs) correta. Vou percorrer as etapas:

Crie o chaveiro

security create-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

neste ponto, o chaveiro está desbloqueado, mas não aparece Keychain Access.

Adicione o novo chaveiro à lista de pesquisa

security list-keychains -s "${KEYCHAIN_NAME}" "${OLD_KEYCHAIN_NAMES[@]}"

Adicione o novo chaveiro à lista. Se você não pegar primeiro a lista original, list-keychainsnão terá mais login.keychainna sua lista de pesquisa.

Desbloqueie o chaveiro

security unlock-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

Isso é redundante se você criou o Keychain acima, mas se o Keychain já existir, será necessário.

Remova os padrões do chaveiro

security set-keychain-settings "${TESTING_KEYCHAIN}"

Ao não especificar nenhum argumento, isso definirá o tempo limite do bloqueio automático como ilimitado e removerá o bloqueio automático no modo de suspensão.

Importe seus certificados de assinatura de um arquivo .p12

security import "${DIST_CER}" -P "${CERTIFICATE_PASSWORD}" -k "${KEYCHAIN_NAME}" -T /usr/bin/codesign

Importe os certificados e dê codesignacesso através da -Topção

Defina a ACL no chaveiro

security set-key-partition-list -S apple-tool:,apple: -s -k "${KEYCHAIN_PASSWORD}" "${KEYCHAIN_NAME}"

Este é um requisito que muitas pessoas sentem falta. Você pode ver o que o macOS faz usando o dump-keychain. Que, no caso da assinatura em código, requer apple:e apple-tool:. -srefere-se à assinatura de certificados.

Gitlab-Runner, Jenkins e similares

Uma coisa muito importante para qualquer corredor do tipo CI ou sistema de construção é garantir que o processo seja iniciado launchdcorretamente. Verifique se o seu plist contém <SessionCreate> </true>.

Não corresponder corretamente o proprietário do chaveiro ao processo de compilação e garantir que uma sessão de segurança seja criada resultará em todos os tipos de dores de cabeça. Em termos de diagnóstico, você pode apresentar list-keychainse ver se a saída corresponde às suas expectativas.

Isto é da launchd.plistpágina de manual:

SessionCreate <boolean>

Essa chave especifica que o trabalho deve ser gerado em uma nova sessão de auditoria de segurança, em vez da qual pertence a sessão padrão para o contexto. Veja auditon (2) para detalhes.

UserName <string>

Essa chave opcional especifica o usuário para executar o trabalho como. Essa chave é aplicável apenas aos serviços carregados no domínio do sistema privilegiado.

GroupName <string>

Essa chave opcional especifica o grupo para executar o trabalho como. Essa chave é aplicável apenas aos serviços carregados no domínio do sistema privilegiado. Se UserName estiver definido e GroupName não, o grupo será definido como o grupo principal do usuário.

Finalmente codeign

Você pode procurar o hash de certificados de assinatura usando find-identity

security find-identity -p codesigning -v

Codifique uma estrutura, dylib, etc.

/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" "$SIGNABLE"

Codificar o pacote de aplicativos

/usr/bin/codesign --verbose=4 -f -s "$SIGNER_HASH" --entitlements entitlements.xcent "$SIGNABLE"

Notas finais - se você observar como o Xcode o faz, ele define o CODESIGN_ALLOCATEuso do contido no Xcode, e não no /usr/bin.

export CODESIGN_ALLOCATE="$( xcrun --find codesign_allocate )"

O caminho de pesquisa é definido como ${PLATFORM_PATH}:${TOOLCHAIN_PATH}:${PATH}, onde o caminho PLATFORM é o diretório / usr / bin do SDK de destino especificado e TOOLCHAIN_PATH é o / usr / bin das ferramentas host do Xcode.

Coloque suas chaves no chaveiro do sistema

Então este é o comando que funciona. -Aé impedir que o Mac peça a senha. A importação para o system.keychain não requer uma GUI.

sudo security import <cert.p12> -k "/Library/Keychains/System.keychain" -P <passphrase> -A

Meu chaveiro estava trancado. Ele resistiu meus avanços para mudar esse fato ...

Keychain Access-> Keychain First Aid-> Repair, et voilá !

Desbloquear o chaveiro não é suficiente. Você também deve definir o acesso da chave privada para "Permitir que todos os aplicativos acessem este item". E para fazer isso na linha de comando, é necessário reimportar a chave. Então, para entender as coisas de cada vez:

Desbloqueie o chaveiro de login, se estiver bloqueado. Porém, não deve estar bloqueado, mas de qualquer maneira, veja como você faz isso:

security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "~/Library/Keychains/login.keychain"

Se, por algum motivo, sua máquina de compilação tiver o chaveiro de login bloqueado e você não desejar expor essa senha em um script, deverá usar um chaveiro diferente. Você pode criar um no local e usá-lo no comando anterior e no seguinte. Para criar um no local:

security create-keychain -p 'temporaryPassword' MyKeychain.keychain
security list-keychains -d user -s login.keychain MyKeychain.keychain

Em seguida, importe seus certificados e chaves privadas associadas para o chaveiro de login usando o parâmetro -A. Note que você não precisa sudo para tudo isso ...

security import <cert.p12> -k "~/Library/Keychains/login.keychain" -P <passphrase> -A

O parâmetro -A é o que fará com que sua chave privada seja definida como "Permitir que todos os aplicativos acessem este item"

Portanto, usando tudo isso, você poderá criar um script que instale o certificado necessário para criar um ipa de lançamento e assiná-lo sem aviso prévio. Você pode armazenar o arquivo .p12 no seu repositório, para que qualquer máquina possa criar seu ipa sem a necessidade de configuração manual.

Além de desbloquear o chaveiro (conforme mencionado em outras respostas), você precisa permitir o acesso de todos os aplicativos ao token de autenticação Xcode no chaveiro:

• Selecione o chaveiro "login"
• Selecione a categoria "Todos os itens"
• Procure por palavra-chave "xcode"
• Selecione "Permitir que todos os aplicativos acessem este item" para todos os tokens do Xcode
• Não se esqueça de adicionar a etapa de desbloqueio do chaveiro (das respostas anteriores)

Importe suas chaves para as chaves do sistema. Você pode usar este comando:

sudo security import YourKey.p12 -k /Library/Keychains/System.keychain -P PasswordToYourKey -T /usr/bin/codesign

Então, eu tentei todas as respostas aqui e algo não estava bem. Finalmente, descobri que quando reiniciei meu serviço de IC, ele estava sendo executado com um usuário diferente do que eu esperava. Mudar para o usuário que realmente tinha acesso à chave em sua cadeia de login corrigiu tudo. Isso pode não ser um problema comum, mas queria documentar minha razão específica para esse erro, caso isso aconteça com outras pessoas.

Para mim, nada funcionou parece ter que reinstalar o Xcode novamente. Jenkins continua dando o mesmo erro. Você economizaria muito tempo se apenas movesse a instalação do Xcode para a Lixeira e a reinstalasse. Certifique-se de executar o comando codesign na linha de comando pelo menos uma vez.

Mesmo depois, se você receber o mesmo erro, tente definir 'Desbloquear chaveiro?' dentro do Jenkins e localize seu login.keychain em /Users/${USER}/Library/Keychains/login.keychain

Espero que Deus esteja com você depois disso.

No meu caso, isso foi causado por um keychain sendo criado com um tempo limite padrão de 300s e uma compilação longa de xcode com duração superior a 300s. A solução alternativa, para mim, era invocar:

security set-keychain-settings -t <longer timeout in seconds> <keychain>

imediatamente após a criação do chaveiro temporário.

Passei por todas essas sugestões e ainda estava tendo problemas para usar a via rápida gymem um trabalho da Jenkins. Eu tinha o certificado instalado e o chaveiro desbloqueado e consegui assinar o código no escravo quando executei manualmente o comando codesign na linha de comando.

Como solução alternativa, se Jenkins se conectar ao escravo usando JNLP em vez de SSH, você poderá assinar o código.

Para mim, isso acontece quando há um segundo chaveiro adicionado manualmente e está bloqueado. Por alguma razão, codesigntenta acessar o conjunto de chaves bloqueadas e falha, mesmo que os certificados estejam no conjunto de chaves de logon (e estejam desbloqueados). Desbloquear o segundo resolve o problema. Apenas não faz sentido para mim.

Depois de tentar várias das soluções acima. Percebi que um dos fatores que eu tinha era que estava iniciando a compilação usando o ION Console. Quando voltei a fazer a compilação a partir do aplicativo Terminal, tudo funcionou bem.