Electron: Electron quebrado no OS X em aplicativos Apple Sandboxed (App Store)

A versão Electron foi a versão 0.36.1 MAS.
Testei com a versão 0.36.0 OS X; infelizmente ocorreu o mesmo.
Obrigado novamente.

Sobre este assunto, já testei com v0.35.x (mas builds). Embora ainda esteja dando os logs deny mach-lookup , o problema gráfico não parece ocorrer.
Também é preciso mencionar: Para as compilações mas (testado com compilações mas v0.36.0-v.36.7), antes de assinar com direitos de sandbox, o aplicativo funciona bem. O problema gráfico só aparece após a assinatura do código.
As compilações darwin não são afetadas, pois não são assinadas com direitos para sandboxing.

Mesmo aqui. Estou voltando para v0.35.x por enquanto. Talvez precisemos esperar até que a atualização para o Chrome 48 em atom/libchromiumcontent#175 chegue.

Eu tenho o mesmo problema e estou usando a versão mais recente do MAS (0.37.1). Esta última compilação atualiza para o Chromium 49, então pensei que poderia resolver isso, mas não resolve.

Acabei de testar alguns dos lançamentos recentes do Electron:

• Electron v0.36.x darwin constrói todos funcionam muito bem.
• As compilações do Electron v0.36.x mas funcionam com alguma falha nos gráficos após o sandbox (presumo com transições e animações CSS, ou para coisas relacionadas à GPU)?
• Electron v0.37.0 darwin/mas falha ao iniciar (corrigido em v0.37.1).
• Electron v0.37.1 darwin build tem algumas falhas como aquela em Electron v0.36.x mas builds (antes e depois do código assinado para distribuição).
• A compilação mas do Electron v0.37.1 tem algumas falhas como a das compilações mas do Electron v0.36.x; no entanto, ele não carrega depois de sandboxed?

(cont.) ao assinar apenas com direitos de sandbox para o Electron v0.37.1 mas build:

3/14/16 5:23:51.171 PM sandboxd[395]: ([3742]) test-0.37.1 Help(3742) deny mach-lookup org.chromium.Chromium.rohitfork.3741
3/14/16 5:23:51.311 PM sandboxd[395]: ([3743]) test-0.37.1 Help(3743) deny mach-lookup org.chromium.Chromium.rohitfork.3741
3/14/16 5:23:51.461 PM sandboxd[395]: ([3744]) test-0.37.1 Help(3744) deny mach-lookup org.chromium.Chromium.rohitfork.3741
3/14/16 5:23:51.719 PM Electron[3741]: __net_helper_get_connection_block_invoke_3 could not connect to networkd
3/14/16 5:23:51.719 PM Electron[3741]: __nw_path_evaluator_start_helper_connection_block_invoke net_helper_path_evaluation_start callback failed, dumping backtrace:
        [x86_64] libnetcore-583.20.10
    0   libsystem_network.dylib             0x00007fff96104ba5 __nw_create_backtrace_string + 123
    1   libsystem_network.dylib             0x00007fff9611de68 __nw_path_evaluator_start_helper_connection_block_invoke + 22
    2   libxpc.dylib                        0x00007fff8c19691f _xpc_connection_reply_callout + 26
    3   libxpc.dylib                        0x00007fff8c1968c0 _xpc_connection_call_reply + 36
    4   libdispatch.dylib                   0x00007fff9b90b33f _dispatch_client_callout + 8
    5   libdispatch.dylib                   0x00007fff9b90ff6f _dispatch_queue_drain + 754
    6   libdispatch.dylib                   0x00007fff9b91663b _dispatch_queue_invoke + 549
    7   libdispatch.dylib                   0x00007fff9b90ec87 _dispatch_root_queue_drain + 538
    8   libdispatch.dylib                   0x00007fff9b90ea34 _dispatch_worker_thread3 + 91
    9   libsystem_pthread.dylib             0x00007fff91b6768f _pthread_wqthread + 1129
    10  libsystem_pthread.dylib             0x00007fff91b65365 start_wqthread + 13
3/14/16 5:23:51.720 PM Electron[3741]: nw_path_evaluator_start_helper_connection net_helper_path_evaluation_start failed, dumping backtrace:
        [x86_64] libnetcore-583.20.10
    0   libsystem_network.dylib             0x00007fff96104ba5 __nw_create_backtrace_string + 123
    1   libsystem_network.dylib             0x00007fff9611a228 nw_path_evaluator_start_helper_connection + 196
    2   libdispatch.dylib                   0x00007fff9b916871 _dispatch_call_block_and_release + 12
    3   libdispatch.dylib                   0x00007fff9b90b33f _dispatch_client_callout + 8
    4   libdispatch.dylib                   0x00007fff9b90ff6f _dispatch_queue_drain + 754
    5   libdispatch.dylib                   0x00007fff9b91663b _dispatch_queue_invoke + 549
    6   libdispatch.dylib                   0x00007fff9b90ec87 _dispatch_root_queue_drain + 538
    7   libdispatch.dylib                   0x00007fff9b90ea34 _dispatch_worker_thread3 + 91
    8   libsystem_pthread.dylib             0x00007fff91b6768f _pthread_wqthread + 1129
    9   libsystem_pthread.dylib             0x00007fff91b65365 start_wqthread + 13
3/14/16 5:23:51.917 PM sandboxd[395]: ([3741]) Electron(3741) deny mach-lookup com.apple.network

Achei que o Electron poderia tentar carregar recursos remotos, então adicionei direitos (ainda com sandbox) para o cliente de rede:

3/14/16 5:27:58.223 PM sandboxd[395]: ([3795]) test-0.37.1 Help(3795) deny mach-lookup org.chromium.Chromium.rohitfork.3794
3/14/16 5:27:58.378 PM sandboxd[395]: ([3796]) test-0.37.1 Help(3796) deny mach-lookup org.chromium.Chromium.rohitfork.3794
3/14/16 5:27:58.523 PM sandboxd[395]: ([3797]) test-0.37.1 Help(3797) deny mach-lookup org.chromium.Chromium.rohitfork.3794

Interessante, os logs sobre redes desapareceram. No entanto, o aplicativo ainda não carrega corretamente com algo em branco conforme anexado.

Parece um pouco diferente de https://github.com/atom/electron/issues/3771.

Mesmo problema em 0.37.1.

Parece que o problema vem das compilações recentes da CEF:
http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=13469

FYI: preparou os dois binários Electron-MAS para reproduzir o problema.
https://drive.google.com/folderview?id=0B8jpVsBA-4FrOTllTlZGOU5JeFU&usp=sharing

Electron_v0.35.6-mas.app pode ser iniciado enquanto Electron_v0.37.2-mas.app não funciona. A única diferença entre eles é a versão MAS.

FYI2: FYI https://github.com/electron-userland/electron-osx-sign/wiki/2.-Electron-Compatibility

Acabei de testar; o mesmo do Electron v0.37.1 aparece em v0.37.2.

Pode confirmar isso para 0.37.2

Parece que o problema de inicialização na v0.37.1 foi corrigido na v0.37.2. No entanto, v0.37.2 mas parece falhar quando em sandbox; ele congela com a janela aparecendo.

Usando v0.37.2 com MAS sandbox, posso criar novas janelas do navegador, mas o aplicativo congela depois que chamo browserWindow.loadURL(someURL). Não há erros impressos no console.

v0.36.2 funciona perfeitamente após a assinatura, mas após a assinatura da v0.37.2, o aplicativo continua mostrando "Não respondendo" e nenhuma janela apareceu.

Eu tenho o mesmo problema que @ fuermosi777. O aplicativo assinado (v0.37.2) continuou sem responder enquanto funcionava perfeitamente com a v0.35.4.

Logs relacionados aqui: https://gist.github.com/luin/33074d4f340aba0cc000

Olá, sou gerente de produto da JANDI , uma plataforma de mensagens comerciais da Coreia do Sul, que está sendo usada por dezenas de milhares de usuários ativos todos os dias. Estamos tentando mudar para o Electron para nosso aplicativo da web, mas esse problema específico é um grande obstáculo para lançarmos no MAS. Eu realmente desejo que esse problema seja resolvido em um futuro próximo para que possamos adicionar meu produto à lista de serviços usados ​​pela Electron. Sempre valorizando o trabalho árduo da equipe. Obrigado.

Acabei de testar; o mesmo do Electron v0.37.1 aparece em v0.37.2.

Ei, apenas algumas atualizações com meus testes com v0.37.3:

Antes do sandboxing/codesign:

• darwin build funciona, com alguns pequenos problemas gráficos.
• mas construa o mesmo que acima.

Após o sandboxing/codesign:

• darwin build tem alguns problemas gráficos desenhando os elementos ao animar, até onde eu testei.
• mas build realmente não carrega a página da web e congela. Ele não trava sozinho, precisa ser finalizado.

Estou pensando em mudar um título para este problema, pois rohitfork e iosurfacemgr não são os fatores reais que causam esses problemas. :confuso:

mesmo problema, aguardo solução

triste coisa que eu preciso API introduzido em 0.36.11 e não pode simplesmente usar mas build antigo.
alguma idéia de solução alternativa?

Este é um bug super importante para nós no Slack, provavelmente veremos isso em breve

Para as pessoas interessadas em corrigir isso, aqui estão algumas dicas:

• A causa raiz é após o sandboxing, o sistema IPC do Chromium começa a ter problemas, em 0,36 o processo de GPU não pode ser iniciado e em 0,37, mesmo o processo de renderização não pode ser executado.
• Isso começa a acontecer a partir de 0,36, que atualiza o Chromium de 45 para 47.
• Acredito que isso ocorra porque o Chromium começou a usar XPC em vez de mensagens brutas de mach para IPC.

Problemas relacionados no Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=382931
https://bugs.chromium.org/p/chromium/issues/detail?id=367863

Uma solução possível é forçar o uso do sistema antigo definindo is_yosemite_or_later_ para false em PreExecDelegate::PreExecDelegate :
https://code.google.com/p/chromium/codesearch#chromium/src/sandbox/mac/pre_exec_delegate.cc &sq= package:chromium&type=cs&l=37

Mas a partir do problema do Chromium, eles mudaram para usar o XPC porque, no Yosemite, o antigo implementado não é compatível com o sistema operacional e o travamento acontece.

@zcbenz Parte do problema é que o nome XPC é sufixado com um PID, portanto, é impossível incluir nos direitos. Podemos apenas remover o sufixo e instruir as pessoas a incluir o nome XPC?

@paulcbetts Não tenho certeza, não tive tempo de dar uma olhada profunda nisso.

@zcbenz Deixe-me tentar configurar com a criação de conteúdo libchromium personalizado e eu tentarei amanhã

Para as pessoas que estão assistindo a esse problema, basta seguir o guia mais recente para obter o Sandbox do Electron para Mac App Store, não há necessidade de esperar pelo próximo lançamento.

A principal mudança é adicionar uma entrada aos direitos:

    <key>com.apple.security.temporary-exception.sbpl</key>
    <string>(allow mach-lookup (global-name-regex #"^org.chromium.Chromium.rohitfork.[0-9]+$"))</string>

Oi @zcbenz , obrigado por sugerir esta solução! 👍 No entanto, é bastante incerto se é mack-lookup que impede o Electron de se comportar normalmente após o codesign; de meus testes agora com Electron v0.37.7 tanto darwin quanto mas, os gráficos ainda parecem um pouco glitchy quando as transições CSS ocorrem. Posso perguntar se há alguma opinião sobre isso? Muito obrigado, e novamente a esta questão.
PS: Gostaria de saber se a exceção temporária passará na revisão mas. 😕 Eu realmente não tenho uma versão funcional para envio ao iTC.

FYI: Enviei um aplicativo (electron 0.37.3) com essas alterações e foi aprovado.

@herrmannplatz Obrigado pela informação! 👍
Ainda estou me perguntando se há algum acompanhamento nos gráficos... Posso perguntar se os problemas relacionados à GPU também foram resolvidos? Desde já, obrigado.

@zcbenz Obrigado pela solução alternativa. Consegui executar meu aplicativo bem. No entanto, ainda estou recebendo alguns erros no meu console. Você tem alguma ideia do que são esses logs do console? Quais são as consequências se eu for com eles? E como posso resolver isso?

4/27/16 10:30:00.325 PM taskgated[110]: no application identifier provided, can't use provisioning profiles [pid=4904] 
4/27/16 10:30:00.000 PM kernel[0]: Sandbox: SampleApp(4904) deny file-read-data / 
4/27/16 10:30:10.000 PM kernel[0]: Sandbox: SampleApp(4904) deny file-read-data /Users/hp011235/Library/Preferences/com.apple.symbolichotkeys.plist

@herrmannplatz Acabei de receber a seguinte rejeição:

minha explicação para submissão:

Este aplicativo aproveita o Chromium para oferecer nossa experiência. Incluído no aplicativo está o Chromium, que usa a porta Mach para sua arquitetura multiprocesso. A string usada é: (allow mach-lookup (global-name-regex #"^org.chromium.Chromium.rohitfork.[0-9]+$"))

O que você fez de diferente para ser aceito?

@zcbenz Fui rejeitado pela Apple para o direito temporário, alguma solução alternativa?

Parece uma tomada de decisão arbitrária típica de uma loja de aplicativos. Vou enviar meu aplicativo hoje, dedos cruzados...

@mcfedr boa sorte com seu envio de iTC!
(Ainda estou pensando se é mais compatível fazer fallback para v0.35.x porque funciona muito bem... 😕 Não tenho muito tempo recentemente, mas vou ver se há alguma correção legal com o Chromium.)

Olá, podemos reabrir este problema? Acabei de testar v1.1.3 e v1.2.0 com as especificações de assinatura descritas em https://github.com/electron/electron/blob/master/docs/tutorial/mac-app-store-submission-guide.md . Não sei por que, mas o aplicativo mas congela no lançamento após o sandbox?
Qualquer um que esteja passando pelo mesmo problema ou sou apenas eu quem encontrou isso ... A compilação do Darwin funciona (bem sem sandbox).

@sethlu Meu aplicativo também começou a congelar quando colocado em sandbox após atualizar o Electron da v1.1.0 para 1.2.0. O problema desapareceu depois que atualizei o electron-packager para a versão mais recente e adicionei as chaves com.apple.security.application-groups e ElectronTeamID conforme descrito no guia de envio atualizado do MAS.

@jarek-foksa ótimo! Obrigado por seu comentário. Eu estava reconstruindo com a v1.1.3 e lançando a v1.2.0... Percebi porque não funcionou antes. 😸
Obrigado a @zcbenz por introduzir esse mecanismo; funcionou perfeitamente até agora! Parece que todas as mensagens de erro desapareceram com grupos de aplicativos.

Meu aplicativo 1.2.0 também não inicia mais depois que eu o assinei de acordo com o guia de envio da loja de aplicativos mais recente. Ele apenas mostra brevemente o ícone e depois fecha novamente.

Quando eu removo a última linha de codesign:
codesign -s "$APP_KEY" -f --entitlements "$PARENT_PLIST" "$APP_PATH"
O aplicativo é aberto novamente, mas com esta mensagem de erro: "O processo não está em um sandbox herdado".

Quando eu removo a penúltima linha:
codesign -s "$APP_KEY" -f --entitlements "$CHILD_PLIST" "$APP_PATH/Contents/MacOS/$APP"
O aplicativo funciona novamente, mas não está mais totalmente assinado, é claro.

Eu segui as instruções de perto e não sei o que está errado. Além disso, quando instalo o aplicativo através do arquivo pkg, ele não será executado.

@Janneman84 se você estiver atualizando para 1.2, você precisa atualizar seus direitos, verifique os documentos da loja de aplicativos

Por favor, seja mais específico, eu acreditava que o guia atual está atualizado:
https://github.com/electron/electron/blob/master/docs/tutorial/mac-app-store-submission-guide.md

Você pode me dizer o que, de acordo com você, está faltando e onde?

@Janneman84 Você já adicionou ElectronTeamID ao Info.plist (conforme exigido pela versão Electron >= 1.1.1) ainda? Caso contrário, você pode verificar se com.apple.security.application-groups foi configurado corretamente conforme descrito no documento em seu arquivo de direitos, que deve ser TEAM_ID.app.bundle.id . Deixe-nos saber se tudo foi verificado, mas o erro persiste.

Segui as instruções cuidadosamente, incluindo a adição do ElectronTeamID no Info.plist e o ID do pacote no outro arquivo. Já tentei várias vezes.

Existe alguma maneira de obter algum tipo de log do acidente? Tudo o que acontece agora é que ele abre e fecha novamente, nada mais.

@Janneman84 você daria uma chance a electron-osx-sign ? Não tenho muita certeza de onde a assinatura do código falhou. Isso pode ser feito com o seguinte script:

# May install the module with: npm install -g electron-osx-sign
export DEBUG=electron-osx-sign*
electron-osx-sign path/to/my.app

Vale a pena notar que com export DEBUG=electron-osx-sign* você visualiza o log completo durante a assinatura. Você riscaria algumas de suas informações privadas primeiro e as postaria aqui?

Podemos apenas usar os direitos padrão para que o aplicativo seja executado primeiro após o sandbox, acho que se você não tiver um código na inicialização que acesse partes do sistema que precisam de chaves de direitos.

Ok, comecei com um aplicativo não assinado limpo (que é executado) e adicionei o ID da equipe ao Info.plist. Então eu tentei elétron-osx-sign. Primeiro, recebi "Nenhuma identidade encontrada para assinatura".
Então eu adicionei manualmente a chave do aplicativo com --identity=1662E * *, agora funcionou (sem erros).
No entanto, o arquivo do aplicativo assinado não será mais executado, mesmo problema de antes.

A propósito, criei o aplicativo usando o último gulp-electron, isso importa?

  electron-osx-sign Signing application... +0ms
  electron-osx-sign > application         myapp.app/ +2ms
  electron-osx-sign > platform            mas +2ms
  electron-osx-sign > entitlements        /usr/local/lib/node_modules/electron-osx-sign/default.mas.entitlements +0ms
  electron-osx-sign > child-entitlements  /usr/local/lib/node_modules/electron-osx-sign/default.mas.inherit.entitlements +0ms
  electron-osx-sign > additional-binaries  +1ms
  electron-osx-sign > identity            1662E**** +0ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework +90ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libffmpeg.dylib +2s
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libnode.dylib +485ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Framework.framework +633ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Helper EH.app/Contents/MacOS/Electron Helper EH +2s
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Helper EH.app +319ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Helper NP.app/Contents/MacOS/Electron Helper NP +273ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Helper NP.app +267ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS/Electron Helper +394ms
  electron-osx-sign Signing... myapp.app/Contents/Frameworks/Electron Helper.app +399ms
  electron-osx-sign Signing... myapp.app/Contents/MacOS/Electron +390ms
  electron-osx-sign Signing... myapp.app/ +600ms
  electron-osx-sign Verifying sign... +529ms
  electron-osx-sign Verifying entitlements... +166ms
Application signed: myapp.app/

@Janneman84 bem, você pode verificar no seu aplicativo KeyChain Access de Utilities ou com $ security find-identity -v -p codesigning que você tem 3rd Party Mac Developer Application: * ?

Estou pensando se um certificado diferente é usado com a assinatura.

Acho que estou tendo o mesmo problema que @Janneman84. Eu posso construir meu aplicativo para "mas" e ele funciona bem. Mas quando eu assino (sem problemas durante a assinatura), recebo vários erros relacionados ao sandbox (veja abaixo). Eu tenho o certificado de aplicativo de desenvolvedor Mac de terceiros.

Consegui criar e assinar a versão "darwin" do aplicativo (necessário assinar alguns componentes adicionais no pacote de aplicativos) e funcionou bem, mas foi rejeitado pelo MAS por usar APIs QuickTime ou QTKit. Na verdade, parece que a compilação "darwin" agora tem o mesmo problema para mim - talvez eu tenha atualizado algum componente como o electron-packager e isso causou o problema ...

6/8/16 09:20:24.176 taskgated[472]: no application identifier provided, can't use provisioning profiles [pid=54551]
6/8/16 09:20:24.997 com.apple.xpc.launchd[1]: (com.apple.ReportCrash[54553]) Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.ReportCrash
6/8/16 09:20:25.869 MyElectronApp[54551]: __net_helper_get_connection_block_invoke_3 could not connect to networkd
6/8/16 09:20:25.869 MyElectronApp[54551]: __nw_path_evaluator_start_helper_connection_block_invoke net_helper_path_evaluation_start callback failed, dumping backtrace:
        [x86_64] libnetcore-583.50.1
    0   libsystem_network.dylib             0x00007fff92595de9 __nw_create_backtrace_string + 123
    1   libsystem_network.dylib             0x00007fff925b058f __nw_path_evaluator_start_helper_connection_block_invoke + 22
    2   libxpc.dylib                        0x00007fff8901a333 _xpc_connection_reply_callout + 26
    3   libxpc.dylib                        0x00007fff8901a2d4 _xpc_connection_call_reply + 36
    4   libdispatch.dylib                   0x00007fff8733740b _dispatch_client_callout + 8
    5   libdispatch.dylib                   0x00007fff8733c03b _dispatch_queue_drain + 754
    6   libdispatch.dylib                   0x00007fff87342707 _dispatch_queue_invoke + 549
    7   libdispatch.dylib                   0x00007fff8733ad53 _dispatch_root_queue_drain + 538
    8   libdispatch.dylib                   0x00007fff8733ab00 _dispatch_worker_thread3 + 91
    9   libsystem_pthread.dylib             0x00007fff86ab04de _pthread_wqthread + 1129
    10  libsystem_pthread.dylib             0x00007fff86aae341 start_wqthread + 13
6/8/16 09:20:25.870 MyElectronApp[54551]: nw_path_evaluator_start_helper_connection net_helper_path_evaluation_start failed, dumping backtrace:
        [x86_64] libnetcore-583.50.1
    0   libsystem_network.dylib             0x00007fff92595de9 __nw_create_backtrace_string + 123
    1   libsystem_network.dylib             0x00007fff925ac89f nw_path_evaluator_start_helper_connection + 196
    2   libdispatch.dylib                   0x00007fff8734293d _dispatch_call_block_and_release + 12
    3   libdispatch.dylib                   0x00007fff8733740b _dispatch_client_callout + 8
    4   libdispatch.dylib                   0x00007fff8733c03b _dispatch_queue_drain + 754
    5   libdispatch.dylib                   0x00007fff87342707 _dispatch_queue_invoke + 549
    6   libdispatch.dylib                   0x00007fff8733ad53 _dispatch_root_queue_drain + 538
    7   libdispatch.dylib                   0x00007fff8733ab00 _dispatch_worker_thread3 + 91
    8   libsystem_pthread.dylib             0x00007fff86ab04de _pthread_wqthread + 1129
    9   libsystem_pthread.dylib             0x00007fff86aae341 start_wqthread + 13
6/8/16 09:20:26.015 sandboxd[53153]: ([54552]) MyElectronApp Helper(54552) deny forbidden-sandbox-reinit
6/8/16 09:20:26.042 sandboxd[53153]: ([54554]) MyElectronApp Helper(54554) deny forbidden-sandbox-reinit
6/8/16 09:20:26.067 sandboxd[53153]: ([54555]) MyElectronApp Helper(54555) deny forbidden-sandbox-reinit
...

@Janneman84 @masonicboom Desculpe, mas terei que investigar um pouco mais antes de saber o que exatamente causa esse problema, com referência à mensagem de erro de taskgated .
No entanto, você poderia tentar criar um caso de teste com electron-quick-start e ver se o codesign é aprovado com o lançamento do aplicativo com êxito? Em seguida, podemos excluir a falha nas identidades de assinatura de código.

Também @Janneman84 , não tenho certeza se gulp-electron suporta compilação nativa mas . Você tentou remover Squirrel.framework ou qualquer coisa de dentro de .app/Contents/Frameworks antes de assinar?

Você pode exibir seus comandos com gulp-electron (excluindo qualquer informação sensível)?

Na verdade, eu sorrateiramente substituí o aplicativo na pasta de cache pela versão mas para que o gulp-electron usasse esse ao compilar. O aplicativo que ele cria não possui a estrutura Squirrel ou outras coisas que a versão mas não deveria ter. Todas as pastas e arquivos necessários estão lá e funciona bem antes de assinar. Vou tentar um empacotador diferente amanhã só para ter certeza.

Também descobri que estava usando um certificado errado. Eu consertei isso agora, mas o problema ainda persiste, também ao usar o electron-osx-sign.

Um problema semelhante aqui https://github.com/electron-userland/electron-osx-sign/issues/59

Acabei de fazer alguns testes com o empacotamento de diferentes versões do Electron e percebi que podem ser as etapas de assinatura adicionais, que de fato resolveram alguns problemas, que causaram o problema recente dos produtos de assinatura de código. Acho que não há nada que provavelmente deu errado durante seus processos de assinatura @Janneman84 @masonicboom.

Eu tentei remover o grupo de aplicativos dos direitos que obviamente levam ao aplicativo travado na inicialização (e é por isso que ElectronTeamID é introduzido), mas o log de erros desapareceu do Console. Então, provavelmente, a única razão para a emissão de no application identifier provided... é essa especificação adicional que fizemos nos direitos.

Até agora, não pensei muito em superar isso, mas a abordagem do grupo de aplicativos é muito bem-vinda. Eu saberei onde encontrar qualquer informação útil.

Olá, estou de volta com provavelmente uma resposta parcialmente certa que começarei a redigir tmrw.

O que aprendi pesquisando, em algumas frases bonitas, é o seguinte:

• A Apple começou a desabilitar testes locais de aplicativos enviados para o MAS há algum tempo; no entanto, testes locais podem ser feitos com provisões de desenvolvimento (ou seja, dispositivos limitados registrados com seus UUIDs, eu acho). É como se tornar um iOS onde você precisa ter seus iPhones/iPads registrados antes de testar nos simuladores.
• Há mais algumas chaves de direito a serem adicionadas para que o aplicativo seja executado, tanto para teste de desenvolvimento/produção; no entanto, depois de adicionar alguns exigidos pelo envio do MAS, seu aplicativo falhará no início 😕, mas tudo bem ser enviado para revisão em uma versão de produção. (Vou descobrir uma maneira melhor de expressar isso tmrw.)
• Há um perfil de provisionamento incorporado embedded.provisionprofile que precisa ser colocado na pasta Contents do aplicativo lacrado para revisão do MAS. (E isso fez com que o aplicativo resistisse parcialmente ao lançamento ao testar localmente para uma versão de produção.)
• taskgated intervém quando o grupo de aplicativos é definido (da minha observação) e procura por perfis de provisionamento ... Ou de um perfil incorporado (como o que os desenvolvedores do iOS sempre trabalham) ou de um perfil de desenvolvimento instalado (como no ponto 1).

Eu sei que algumas das palavras acima não fazem muito sentido. No entanto, isso deve se aplicar apenas a situações em que usamos grupos de aplicativos, eu acho. Com as versões anteriores do Electron (<1.1.1), não há necessidade de se preocupar muito, pois nada apenas sendo dito é realmente necessário.

Algumas referências:

• https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/AppStoreDistributionTutorial/LaunchingYourApponDevices/LaunchingYourApponDevices.html
• https://developer.apple.com/library/mac/qa/qa1884/_index.html
• https://developer.apple.com/library/mac/qa/qa1778/_index.html
• https://developer.apple.com/library/ios/qa/qa1710/_index.html

Desculpe, mas tenho perdido o controle de vários outros recursos... Os acima são diretamente da Apple. Tbh, será muito divertido trabalhar com distribuição MAS a partir de agora.

@Janneman84 @masonicboom @jpittner Você se importaria de verificar https://github.com/sethlu/electron-distribution-guide/blob/master/DevelopmentSignedApplication.md? Eu elaborei um procedimento de assinatura atualizado/conceitual que permite que o aplicativo seja executado com grupos de aplicativos habilitados. Eu tenho meu aplicativo electron-quick-start rodando com isso e sandbox habilitado.

No entanto, observe que este documento é apenas para teste em sua máquina com mas build. Depois que um segundo documento for rascunhado no envio para revisão, espero que até amanhã eu tenha mais informações para que seu aplicativo possa ser executado na Mac App Store. (Desculpe pela contagem de palavras... É um pouco prolixo, peço desculpas.)

@sethlu Estou muito curioso para saber como você conseguiu descobrir essas coisas! Para o que vale a pena, aqui é onde posso obter o aplicativo seguindo suas instruções (dos logs do console). O aplicativo trava, mas pelo menos as mensagens de erro fazem algum sentido e voltam aos dias anteriores ao grupo de aplicativos, em vez de dizer coisas bobas como nenhum codificador para avc1 encontrado.

06-10-2016 18:47:20.069 PM taskgated-helper[78694]: perfil de provisionamento incorporado validado: file:///Users/jan/workspace/MyApp.app/Contents/embedded.provisionprofile
06/10/2016 18:47:20.069 PM taskgated-helper[78694]: encontrado 1 perfis de provisionamento
06-10-2016 18:47:20.069 PM taskgated-helper[78694]: permitindo direitos para pid=78704 devido ao perfil de provisionamento
06-10-2016 18:47:20:631 PM MyApp Helper[78706]: GVA info: idx do scaler preferido 0
6-10-2016 18:47:20.662 PM sandboxd[3764]: ([78706]) MyApp Helper(78706) deny mach-lookup com.me.MyApp.rohitfork.78704
6-10-2016 18:47:20.782 PM sandboxd[3764]: ([78707]) MyApp Helper(78707) deny mach-lookup com.me.MyApp.rohitfork.78704
6-10-2016 18:47:21.463 PM MyApp[78704]: __net_helper_get_connection_block_invoke_3 não pôde se conectar à rede
6-10-2016 18:47:21:464 PM MyApp[78704]: __nw_path_evaluator_start_helper_connection_block_invoke net_helper_path_evaluation_start

Os direitos dos pais estão abaixo. os direitos filho são como de costume com a chave herdada e a chave do sandbox.

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.application-groups</key>
    <array>
            <string>*******EKS.com.me.myApp</string>
    </array>
    <key>com.apple.security.files.user-selected.read-write</key>
    <true/>
    <key>com.apple.application-identifier</key>
    <string>*******EKS.com.me.myApp</string>
    <key>com.apple.developer.team-identifier</key>
    <string>*******EKS</string>
    <key>com.apple.security.temporary-exception.shared-preference.read-only</key>
    <array>
            <string>com.apple.symbolichotkeys</string>
      </array>
 </dict>
  </plist>

Assinado com o script, com binário adicional do spellchecker.node assinado.

Codesign --verify --deep dá

: válido em disco
: satisfaz seu Requisito Designado

Isso estava assinando com a identidade do Mac Developer (que tem um código diferente em vez de * EKS). Tentar assinar o "Aplicativo de desenvolvedor de Mac de terceiros" resulta na falha do aplicativo com o erro - matou com.me.MyApp[pid 78772] porque seu uso do direito com.apple.developer.team-identifier não é permitido (erro código -67050)

@jpittner , tivemos um problema semelhante outro dia, quando um membro de nossa equipe tentou criar uma versão assinada para experimentar o sandbox.

O primeiro problema foi não ter os certificados e chaves privadas adequados no Keychain. O sintoma disso foi que a assinatura falhou com um erro de "identidade não encontrada".

Mas depois disso o problema acabou sendo que a versão do electron-osx-sign que usamos não era a mais recente (0.4.0-beta4), e antes de 0.4.0 não injeta o id do time em *.app/Contents/Info.plist que é necessário após o Electron 1.1.2. O resultado final foi que ele congelou sem erros, exceto o sandboxd deny mach-lookup.rohitfork.em Console.app, como você mencionou acima.

@jpittner Obrigado por experimentar! Houve algumas tentativas e erros lol. A seguir estão alguns dos meus pensamentos sobre suas mensagens de console recebidas:

06-10-2016 18:47:20.069 PM taskgated-helper[78694]: perfil de provisionamento incorporado validado: file:///Users/jan/workspace/MyApp.app/Contents/embedded.provisionprofile
06/10/2016 18:47:20.069 PM taskgated-helper[78694]: encontrado 1 perfis de provisionamento
06-10-2016 18:47:20.069 PM taskgated-helper[78694]: permitindo direitos para pid=78704 devido ao perfil de provisionamento

Acho que o acima representa que as configurações com assinaturas e perfis de provisionamento estão configuradas corretamente para desenvolvimento.

06-10-2016 18:47:20:631 PM MyApp Helper[78706]: GVA info: idx do scaler preferido 0

Isso ocorre apenas no Helper naturalmente. 😕

6-10-2016 18:47:20.662 PM sandboxd[3764]: ([78706]) MyApp Helper(78706) deny mach-lookup com.me.MyApp.rohitfork.78704
6-10-2016 18:47:20.782 PM sandboxd[3764]: ([78707]) MyApp Helper(78707) deny mach-lookup com.me.MyApp.rohitfork.78704

Você verificaria em seu Info.plist e verificaria se ElectronTeamID foi adicionado, o que segue *******EKS do que parecia ser do seu perfil de provisionamento:

<key>com.apple.developer.team-identifier</key>
<string>*******EKS</string>

Pessoalmente, acho que esse erro foi corrigido com uma atualização anterior do Electron, onde o grupo de aplicativos é usado. Portanto, provavelmente a única causa disso deve ser Info.plist ou o arquivo de direitos, que no seu caso já deve estar configurado corretamente.

6-10-2016 18:47:21.463 PM MyApp[78704]: __net_helper_get_connection_block_invoke_3 não pôde se conectar à rede
6-10-2016 18:47:21:464 PM MyApp[78704]: __nw_path_evaluator_start_helper_connection_block_invoke net_helper_path_evaluation_start

Não sei por que o Chromium começa a reclamar sobre as conexões de rede (caso você não queira acessar servidores remotos). No entanto, você pode levitar esse problema adicionando uma chave de direitos adicional: com.apple.security.network.client para permitir a conexão com o servidor web (ou se não houver um).

Em sua nota ao cantar com 3rd Party Mac Developer Application , o erro deve ocorrer... Isso é dito pela Apple como planejado... Eu não tive tempo de ter isso coberto no meu rascunho no envio ao MAS documento. Mas sim, não há uma maneira possível de testar o aplicativo real a ser enviado para revisão, mas usando o Mac Developer , para cumprir as atualizações modernas da Apple.

No entanto, meio que contornamos isso sorrateiramente, não definindo o grupo de aplicativos!? Ainda não tenho certeza se podemos contornar esses excessos que parecem um pouco desnecessários. No entanto, mesmo em um aplicativo básico de tela em branco em Obj-C/Swift empacotado do Xcode. O esquema de assinatura/teste segue da mesma maneira. 😅 Eu realmente não sei o que a Apple está fazendo, mas a mudança implica um pouco em uma situação paradoxal em que os voos de teste devem estar disponíveis no Mac ... lol.

Deixe-me saber como vai.

@slaskis dos meus testes o identity not found pode ser causado por não especificar com.apple.application-identifier ... meu tentar esses perfis com Electron.

Além disso, não tenho certeza de por que os erros sobre pesquisas de mach ainda persistem 💭 se ElectronTeamID estiver configurado corretamente em Info.plist e com.apple.security.application-groups estiver configurado corretamente no arquivo de direitos. No entanto, não abrimos nenhum PR em relação ao documento mencionado anteriormente, pois o fluxo de trabalho atual não corresponde ao da Apple. Anteriormente, não distinguimos desenvolvimento ou distribuição porque o aplicativo é executado mesmo após o envio do sandbox para o MAS... Não, parece que não deveria.

Ref: https://developer.apple.com/library/mac/qa/qa1884/_index.html

As compilações de distribuição de aplicativos que usam essas tecnologias podem ser enviadas ao iTunes Connect para revisão, mas até então, não têm permissão para serem executadas e são encerradas na inicialização . Isso ocorre porque os perfis de provisionamento de distribuição não contêm uma lista de UUIDs de hardware que restringem o aplicativo a um conjunto específico de dispositivos. Isso é semelhante ao iOS, onde as compilações de distribuição nunca tiveram permissão para serem executadas em um dispositivo.
Recentemente, o direito com.apple.developer.team-identifier foi adicionado a todos os novos perfis de provisionamento do Mac. Isso significa que, daqui para frente, as compilações de distribuição de aplicativos para Mac não podem ser executadas diretamente;
Em vez disso, os desenvolvedores devem adotar o Archive Build Workflow em QA1778: Como reproduzir bugs relatados nos envios da Mac App Store para testar as compilações que planejam enviar para a Mac App Store. No Xcode 6, selecione Exportar como um aplicativo Mac. Você não verá nenhuma chance de selecionar sua identidade de assinatura de desenvolvimento, mas o Xcode exportará o aplicativo do arquivo como foi assinado no momento da compilação. Então o resultado será o mesmo.

Por favor, lembre-se de que algumas das palavras não se aplicam realmente à nossa situação, pois não interferimos no Xcode durante esta parte. suspirar

Caso alguém esteja interessado, estou usando o seguinte script para fazer o procedimento de assinatura de código atual, apenas para acelerar:

APP="MyApp.app"
TEAM_ID="XXXXXXXXXX" # Note this is the actual "team" id, not your personal one that appears to be on your Mac Developer signing identity
DEVELOPMENT_PROVISIONING="development.provisionprofile"
SIGNING_IDENTITY="Mac Developer"

# Copies the development provisioning to inside the app contents
cp "${DEVELOPMENT_PROVISIONING}" "${APP}/Contents/embedded.provisionprofile"
# Adds the ElectronTeamID into Info.plist
plutil -insert ElectronTeamID -string "${TEAM_ID}" "${APP}/Contents/Info.plist"
# Code signs the product... Note the --no-pre-auto-entitlements flag which skips the latest electron-osx-sign feature
electron-osx-sign "${APP}" --entitlements="mas.entitlements" --identity="${SIGNING_IDENTITY}" --no-pre-auto-entitlements

Em mas.entitlements :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.application-identifier</key>
    <string>XXXXXXXXXX.net.mintkit.electron-quick-start</string>
    <key>com.apple.developer.team-identifier</key>
    <string>XXXXXXXXXX</string>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.application-groups</key>
    <array>
        <string>XXXXXXXXXX.net.mintkit.electron-quick-start</string>
    </array>
    <key>com.apple.security.network.client</key>
    <true/>
</dict>
</plist>

Desculpe pelo meu erro em aceitar que o TeamID não varia para uma conta de desenvolvedor... Na verdade, varia. Eu não atualizei electron-osx-sign para usar o ID _Team_ real, que aqui é diferente do que pode ser analisado de sua identidade de desenvolvimento pessoal. Isso deve explicar por que electron-osx-sign não funciona aqui @slaskis. Usamos --no-pre-auto-entitlements para pular todas aquelas automações rápidas introduzidas na versão 0.4.0.

Estou de volta com https://github.com/sethlu/electron-distribution-guide atualizado com guia para submissão ao MAS. No entanto, é recomendável ter Development-signed Application execução antes de passar para Mac App Store Deployment . 😸

@sethlu eu esqueci de mencionar que funciona muito bem para nós agora depois de atualizar para o electron-osx-sign 0.4.0 com o upload para o MAS. Já tivemos alguns lançamentos aceitos pela Apple.

Então, o que fazemos é usar electron-packager para construir o .app, então electron-osx-sign para assinar todos os binários, então depois de testar a versão sandbox, executamos electron-osx-flat para construir um .pkg que então carregamos com o Application Loader.

No entanto, usamos um arquivo de direitos personalizado e não aqueles que o electron-osx-sign adiciona:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.application-groups</key>
    <array>
      <string>XXXXXXXXXX.com.ourapp</string>
    </array>
    <key>com.apple.security.files.user-selected.read-only</key>
    <true/>
    <key>com.apple.security.files.bookmarks.app-scope</key>
    <true/>
  </dict>
</plist>

@sethlu obrigado por toda a sua ajuda. Assinando com seu script acima, não parece mais haver erros flagrantes no console, porém o aplicativo simplesmente não carrega (apenas uma tela branca)

No console, nada que indique erros:

06-11-2016 11:15:09.067 AM taskgated-helper[80923]: Iniciando taskgated-helper
11-6-2016 11:15:09.119 AM taskgated-helper[80923]: perfil de provisionamento incorporado validado: file:///Users/jan/workspace/MyApp.app/Contents/embedded.provisionprofile
06-11-2016 11:15:09.119 AM taskgated-helper[80923]: encontrado 1 perfis de provisionamento
06-11-2016 11:15:09.119 AM taskgated-helper[80923]: permitindo direitos para pid=80922 devido ao perfil de provisionamento
11-6-2016 11:15:09.439 AM MyApp Helper[80925]: GVA info: idx do scaler preferido 0

Direitos:

    <key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.application-groups</key>
<array>
    <string>*******EKS.com.me.myApp</string>
</array>
<key>com.apple.security.files.user-selected.read-write</key>
<true/>
<key>com.apple.application-identifier</key>
<string>******EKS.com.me.myApp</string>
<key>com.apple.developer.team-identifier</key>
<string>********EKS</string>
<key>com.apple.security.temporary-exception.shared-preference.read-only</key>
<array>
    <string>com.apple.symbolichotkeys</string>
</array>
    <key>com.apple.security.network.client</key>
    <true/>

Info.plist agora contém o valor ** EKS.

Da última vez que vi algo assim, as permissões nos arquivos do aplicativo (componente www) estavam incorretas, porém verifiquei que estão definidas corretamente. Eu também tentei com a chave network.server definida como verdadeira, mas ainda assim, apenas uma tela branca.

@slaskis Fico feliz em saber! 😺 Tenho certeza de que aplicativos assinados com electron-osx-sign podem ser executados com pelo menos electron-quick-start . Você pode verificar no Console e confirmar se há algum erro como o seguinte:

6/8/16 09:20:24.176 taskgated[472]: no application identifier provided, can't use provisioning profiles [pid=54551]

Ao testar [email protected] , meu aplicativo pode ser iniciado sem muitos problemas. No entanto, recebi o que foi mostrado acima com o aplicativo de início rápido simples. Não tenho certeza se no application identifier provided pode ser um pouco crônico.

@jpittner Posso perguntar se seu aplicativo agora simplesmente mostra uma tela branca ou literalmente congela com um cursor giratório? Não tenho certeza se o aplicativo está falhando drasticamente após a assinatura do código.

@sethlu apenas uma tela branca, sem cursor giratório. Na verdade pode acessar o menu App (que só tem Quit) e pode sair.

@jpittner O aplicativo deve ser iniciado corretamente, eu acho... Você pode tentar adicionar o seguinte ao seu script main.js , ou equivalente, em algum lugar após a criação da janela, apenas para confirmar que alguma página da web é mostrada?

mainWindow.webContents.openDevTools()

Se as ferramentas de desenvolvimento aparecerem, a página carregada deve ser encontrada em algum lugar nos painéis. Caso contrário, talvez tenhamos que pensar em algumas outras resoluções para esse problema.

@sethlu - parece que um dos módulos de nó que é uma dependência necessária está sendo ignorado pelo electron-packager, o regex que costumava funcionar --ignore=.+\.o$ agora inclui qualquer coisa que termine com o, em vez de .o, o que causou um erro de javascript não capturado (realmente preciso ver como lidar com isso corretamente :) ). mudando para --ignore=.+\\.o$ corrigiu isso, e agora funciona! 🎉

Então agora eu acho que a questão é, a partir daqui, o que eu preciso mudar para poder enviá-lo para a loja de aplicativos? Eu estou supondo que eu não incluo o provisionprofile?

Obrigado por toda sua ajuda!

@jpittner 🎊 Eu recomendaria verificar https://github.com/sethlu/electron-distribution-guide/blob/master/MacAppStoreDeployment.md. Existem apenas algumas pequenas diferenças do fluxo de trabalho de Desenvolvimento assinado-Aplicativo, basicamente substituindo os certs e perfis de provisionamento. Depois de fazer isso (como seu aplicativo agora é executado corretamente), acredito que seu aplicativo está pronto para envio! 😺
Deixe-me saber como foi ~

Acredito que devemos usar perfis de provisionamento (distribuição enquanto trabalhamos no envio ao MAS) para que os grupos de aplicativos sejam permitidos teoricamente e com menos reclamações do console.

Pelo que obtive de volta com o Xcode, o interior de um aplicativo para distribuição dentro do MAS deve ser algo como:

E o que parece dentro de um aplicativo para distribuição, no entanto, fora do MAS deve ser algo como:

Acho que devíamos ter esses perfis de provisionamento, que conseguimos disfarçar com versões anteriores, só para ter certeza de que o resultado não será muito diferente de um aplicativo para Mac feito com Xcode.

@sethlu sim, existem alguns logs assim:

11/06/16 20:55:53,971 taskgated[294]: no application identifier provided, can't use provisioning profiles [pid=97967]
11/06/16 20:55:57,000 kernel[0]: Sandbox: ExampleApp(97967) deny(1) mach-lookup com.apple.networkd

@slaskis Sim, essas devem ser as mensagens de erro que vêm do Console ao iniciar um aplicativo assinado com o [email protected] atual. Não tenho certeza se eles podem significar algo errado, mas as etapas extras podem resolver o problema do identificador não encontrado.

Na verdade, primeiro pensei que essas mensagens levassem a um problema com o lançamento do aplicativo do @jpittner. No entanto, provou ser causado por outra coisa.

Se nada impedir que seu aplicativo seja iniciado de qualquer maneira, tudo bem 😉, apenas o usuário final provavelmente receberá isso em seu console também...

Agora eu estou confuso :)

• Eu atualizei para o mais recente elétron mas pré-construído
• 0.4.0-beta4 do electron-osx-sign
• arquivos plist atualizados como dito no branch master
• leia todo este tópico e o ramo @sethlu do guia
• copiou o perfil de provisionamento de desenvolvimento (estou certo?) na pasta ./Contents no script de compilação

ainda meu aplicativo é capaz de passar na primeira linha da defesa do ITS (está em revisão agora)

mas, ainda assim, quando o executo, posso ver apenas o ícone e, em seguida, ele falha / encerra (o ícone desaparece)
e posso ver erros do console:

7/5/16 17:47:39.451 lsd[476]: LaunchServices: Could not store lsd-identifiers file at /private/var/db/lsd/com.apple.lsdschemes.plist
7/5/16 17:47:39.480 taskgated[485]: no application identifier provided, can't use provisioning profiles [pid=84402]
7/5/16 17:47:40.453 sandboxd[35554]: ([84402]) Grape(84402) deny network-bind /private/var/folders/dr/cw1hncvj5vz4_p44q4nbjzgm0000gn/T/com.ChatGrape/S/SS

estou certo que:

• app tem a capacidade de ser executado no lado da maçã?
  
  
  
  • Enviei a versão sem o perfil de desenvolvedor copiado, devo reenviar?
  
  
• app terá a capacidade de ser executado quando for baixado da loja de aplicativos se for aceito?
• devo fazer outra coisa?

Oi @tyv gostaria de esclarecer a presença do guia: Ele está escrito como uma solução para a mensagem de erro no application identifier provided, can't use provisioning profiles . Se o seu aplicativo eventualmente passar na análise da Apple, não há problema em executá-lo após o download da Mac App Store.

Aqui estão alguns casos e sugestões que tenho:

1. Se o guia (https://github.com/sethlu/electron-distribution-guide/blob/master/MacAppStoreDeployment.md) for usado para criar um aplicativo de implantação da Mac App Store, o aplicativo não deve ser executado porque se destina ao envio .
2. Se o guia (https://github.com/sethlu/electron-distribution-guide/blob/master/DevelopmentSignedApplication.md) for usado para criar um aplicativo assinado pelo desenvolvimento, o aplicativo não deve ser enviado para revisão porque não use certificados de terceiros para assinar aqui realmente.
3. Se estiver assinando apenas com certificados de terceiros sem seguir nenhuma parte do guia (https://github.com/sethlu/electron-distribution-guide), o aplicativo deve estar sendo executado no lançamento com um erro no application identifier provided, can't use provisioning profiles . Se isso não acontecer, deve haver problemas que precisam ser resolvidos em algum lugar.

Então, se acontecer de estarmos com o primeiro caso, não há necessidade de se preocupar muito no momento, acredito. No entanto, se for com o último caso e o aplicativo não iniciar corretamente, talvez seja necessário ajustar o aplicativo um pouco... A mensagem de erro pode ser ignorada como os outros pensei; não é um grande problema tê-lo tanto quanto eu ouvi.

Como seu aplicativo está atualmente em revisão, suponho que podemos esperar antes que o iTC diga alguma coisa.

Seria muito legal se o electron-osx-sign tratasse da correção de direitos automaticamente /cc @sethlu

@paulcbetts não é? https://github.com/electron-userland/electron-osx-sign/blob/master/index.js#L160 -L189

@sethlu obrigado pela resposta, vou relatar de volta.

@tyv Suspeito que muitas pessoas estão sendo pegas aqui: https://github.com/electron-userland/electron-osx-sign/blob/master/index.js#L155 , o que parece exigir que eles preencham pela metade -out seu arquivo PList. electron-osx-sign deve ter apenas uma opção --mas que faz tudo

@paulcbetts Vou revisar um fluxo de assinatura de código melhor ainda esta semana para que ele possa aderir mais ao que a Apple faz. Eu estive pensando em integrar perfis de provisionamento a parte do fluxo de assinatura por um tempo... Atualmente o que electron-osx-sign faz é automatizar o arquivo de direitos e a lista de informações se o sandbox estiver habilitado (por padrão ou pelo usuário entrada de direito de entrada). Se o usuário tiver uma entrada de sandbox em um arquivo de direitos personalizados, tudo deve funcionar bem no momento.

@sethlu Lembre-se, muitos node.js / web devs não têm idéia sobre PLists, portanto, ser Opinião e apenas preencher tudo para eles a partir das informações do package.json pode ser uma coisa melhor (desde que as pessoas possam optar por não participar e escolher seus própria maneira, é claro) - eu diria que a entrada Info.plist é lixo / configurada incorretamente e priorize as informações no package.json o máximo possível

Para esclarecer a opção @paulcbetts que você menciona em https://github.com/electron/electron/issues/3871#issuecomment -230562216 é tudo o que precisamos de acordo com o ponto 1 do comentário @sethlu https://github.com/electron/ electron/issues/3871#issuecomment -230532007 ?

Porque depois de usá-lo o aplicativo não é executado.

Existe um guia organizado como assinar com o uso de electron-osx-sign que apreciam esse problema?

Atualizada:

Se alguém tiver problema de aplicativo não iniciar, porque você lê alguns arquivos no diretório inicial

http://jorgen.tjer.no/post/2011/07/26/home-relative-sandbox-entitlement/

Comentário original:

E mais um (apenas um pouco fora do tópico, mas ainda com uma pequena sobreposição). Eu li o link fornecido https://github.com/electron-userland/electron-osx-sign/wiki/3.-App-Sandbox-and-Entitlements que me direciona para https://developer.apple.com/library /mac/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html

Isso significa que, se meu aplicativo precisa ler arquivos como ~/.aws/credentials , ele não pode estar no sanbdox, portanto, não pode estar na App Store?

Descobri que https://developer.apple.com/library/mac/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/AppSandboxTemporaryExceptionEntitlements.html

Mas tentando

electron-osx-sign APP_PATH APP_PATH/Contents/Resources/app/node_modules/fsevents/build/Release/.node --mas --entitlements="com.apple.security.temporary-exception.files.home-relative-path.read-write"

Dá

Sign failed.
Command failed: codesign --sign 3rd Party Mac Developer Application: lukasz Sielski (ZZZZZZZZZ) -fv --entitlements com.apple.security.temporary-exception.files.home-relative-path.read-write APP_PATH
com.apple.security.temporary-exception.files.home-relative-path.read-write: cannot read entitlement data

Também encontrei agora este http://electron.atom.io/docs/tutorial/mac-app-store-submission-guide/#additional -entitlements significa que meu com.apple.security.temporary-exception.files.home-relative-path.read-write deve estar em parent.plist não em Info.plist . Ao usar electron-osx-sign eu ainda não tinha parent.plist , pois foi criado por ele.

Olá @sielay ,

Existe realmente um guia organizado como assinar com o uso do sinal de elétron-osx que aprecia esse problema?

O mais recente electron-osx-sign ainda não abordou os perfis de provisionamento; no entanto, depois de assinar com os procedimentos (que podem ser feitos por electron-osx-sign ) atualmente descritos nos documentos do Electron, seu aplicativo deve iniciar e funcionar conforme o esperado. Vale a pena notar que haverá mensagens de erro como abaixo lançadas dentro do Console.

7/5/16 17:47:39.451 lsd[476]: LaunchServices: Could not store lsd-identifiers file at /private/var/db/lsd/com.apple.lsdschemes.plist

Após o envio do iTC e, eventualmente, baixado do MAS, é incerto se esse log de erros desaparecerá; O iTC abandona seu aplicativo para distribuição MAS no servidor da Apple para que aqueles que baixam seu aplicativo possam executá-lo sem avisos do Gatekeeper.

Isso significa que, se meu aplicativo precisa ler arquivos como ~/.aws/credentials, ele não pode estar em sanbdox, portanto, não pode estar na App Store?

Seu aplicativo pode não acessar ~/.aws/credentials porque o local está inacessível sem exceções temporárias em seu arquivo de direitos.

Mas tentando

electron-osx-sign APP_PATH APP_PATH/Contents/Resources/app/node_modules/fsevents/build/Release/.node --mas --entitlements="com.apple.security.temporary-exception.files.home-relative-path.read-write"

Dá

Sign failed.
Command failed: codesign --sign 3rd Party Mac Developer Application: lukasz Sielski (ZZZZZZZZZ) -fv --entitlements com.apple.security.temporary-exception.files.home-relative-path.read-write APP_PATH
com.apple.security.temporary-exception.files.home-relative-path.read-write: cannot read entitlement data

Crie um arquivo de direitos personalizado se desejar marcar entradas de direitos adicionais. Eu recomendaria criar app.entitlements ou app.plist , que realmente é apenas o parent.plist mencionado em seu post, acho, com o seguinte conteúdo como base:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.temporary-exception.files.home-relative-path.read-write</key>
    <array>
      <string>/.aws/</string>
    </array>
  </dict>
</plist>

Em seguida, você pode assinar seu pacote de aplicativos com o seguinte comando:

electron-osx-sign APP_PATH APP_PATH/Contents/Resources/app/node_modules/fsevents/build/Release/.node --entitlements="path/to/my.entitlements"

Por --entitlements você pode fornecer app.entitlements ou app.plist , que é essencialmente seu arquivo de direitos personalizados. (Desculpe, mas ainda não podemos inserir entradas de direito diretamente para electron-osx-sign para processamento.)

Além disso, para confirmar que seu procedimento de codesign está correto, você pode ativar a depuração para electron-osx-sign com:

export DEBUG=electron-osx-sign*

E, em seguida, use electron-osx-sign para assinar o código do seu pacote de aplicativos.

Avise-me se houver alguma confusão. 😸 Uma próxima revisão de electron-osx-sign pode ser mais útil com personalizações mais fáceis, eu acho.

@sethlu como eu disse, meu aplicativo depois de assinado não pode ser executado e sair após o lançamento, as mesmas coisas acontecem e nas avaliações da App Store.
e sandboxing ainda são perguntas da App Store, aqui está a resposta:

Desempenho - 2.1
Percebemos que, com um recibo válido instalado, seu aplicativo é encerrado na inicialização. O console informa que o aplicativo "Saiu com código de saída: 173" e o sistema operacional informa que o aplicativo "está danificado e não pode ser aberto". Isso geralmente indica que o aplicativo não está verificando seu recebimento corretamente.

Próximos passos
Revise seu aplicativo e teste-o para garantir que ele seja executado conforme o esperado.

Desempenho - 2.4.5

Determinamos que uma ou mais exceções de direito temporário solicitadas para este aplicativo não são apropriadas e não serão concedidas:

com.apple.security.temporary-exception.sbpl - (permitir pesquisa de mach (global-name-regex #"^org.chromium.Chromium.rohitfork.[0-9]+$"))

Entendemos que isso pode impedir que o aplicativo seja aprovado para a Mac App Store. Recomendamos que você investigue outras formas de implementar a funcionalidade desejada.

Olá @tyv ,

Percebemos que, com um recibo válido instalado, seu aplicativo é encerrado na inicialização. O console informa que o aplicativo "Saiu com código de saída: 173" e o sistema operacional informa que o aplicativo "está danificado e não pode ser aberto". Isso geralmente indica que o aplicativo não está verificando seu recebimento corretamente.

Acho que talvez precisemos começar a ajustar o aplicativo um pouco antes de reenviá-lo ao iTC.

Determinamos que uma ou mais exceções de direito temporário solicitadas para este aplicativo não são apropriadas e não serão concedidas:
com.apple.security.temporary-exception.sbpl - (permitir pesquisa de mach (global-name-regex #"^org.chromium.Chromium.rohitfork.[0-9]+$"))

Tenho certeza de que essa correção de exceção temporária não está mais em uso após a introdução de grupos de aplicativos definindo ElectronTeamID em Info.plist e uma entrada correspondente no arquivo de direitos.

Você exibiria seus direitos personalizados usados ​​para assinatura abaixo? E se estiver usando electron-osx-sign , você também colaria uma cópia dos logs emitidos com env export DEBUG=electron-osx-sign* ? Informe-nos se houver recursos adicionais para sua assinatura de código.

Acho que talvez precisemos começar a ajustar o aplicativo um pouco antes de reenviá-lo ao iTC.

não entendo você

Você exibiria seus direitos personalizados usados ​​para assinatura abaixo?

aqui você pode encontrar plist 's que eu uso ao empacotar o aplicativo https://github.com/ubergrape/grape-electron/tree/master/resources/osx

E se estiver usando electron-osx-sign, você também colaria uma cópia dos logs emitidos com env export DEBUG=electron-osx-sign*?

eu uso js api
aqui está a configuração: https://github.com/ubergrape/grape-electron/blob/master/tasks/release/osx.js#L91

@sethlu aqui está o log de depuração https://gist.github.com/tyv/d96a11c5fde73e3966b0014311a3079f

a principal preocupação é que, depois que eu assino o aplicativo (de diferentes maneiras, sem erros), ele não consegue executá-lo.
ele mesmo se fecha.

@tyv , acho que seu aplicativo está bem assinado. Você pode verificar no Console também para ver se surge algum erro quando seu aplicativo é iniciado? Além disso, eu recomendaria remover a exceção temporária em https://github.com/ubergrape/grape-electron/blob/master/resources/osx/child.plist#L9 -L10 antes de criar outra versão de teste.

@sethlu
eu vejo apenas

7/26/16 13:36:49.427 sandboxd[19719]: ([20302]) Grape(20302) deny network-bind /private/var/folders/dr/cw1hncvj5vz4_p44q4nbjzgm0000gn/T/com.ChatGrape/S/SS

@sethlu aqui está o relatório completo https://gist.github.com/tyv/347298b455b560ea9721cf8ff09d0fe8

E mais um

7/26/16 13:54:54.241 taskgated[509]: no application identifier provided, can't use provisioning profiles [pid=20987]

@sethlu parece que é o mesmo que aqui: electron-userland/electron-osx-sign/issues/59
alguma atualização sobre esse problema?

Oi @tyv , desculpas pela minha resposta tardia; Estive ausente nos últimos dias.

O problema https://github.com/electron-userland/electron-osx-sign/issues/59 Acho que é um pouco diferente na maneira como um problema crítico está no vídeo en/decoder. (No entanto, eu não sei como @jpittner contornou o problema do vídeo en/decodificador... Ou apenas seguindo o fluxo de assinatura conceitual em https://github.com/sethlu/electron-distribution-guide então tudo foi resolvido naturalmente .)

O aplicativo ainda deve ser lançado com no application identifier provided... e sem efeitos significativos até onde eu ouvi 😕. Até agora, acredito que com seu aplicativo assinado corretamente, a única sinalização é realmente apenas deny network-bind ... Deixe-me verificar a resolução.

@As coisas do decodificador/codificador de vídeo desapareceram assim que o pacote foi assinado corretamente. No momento, estou funcionando com a compilação MAS (e posso usar um perfil de provisionamento de desenvolvimento para testá-lo), mas estou tendo problemas para fazer com que a versão assinada pelo ID do desenvolvedor (ou seja, para distribuição não MAS) funcione corretamente!

editar - falou cedo demais. Isso foi com a versão anterior (1.2.x) com 1.3.1. Agora estou tendo problemas para carregar a compilação do MAS na minha máquina de desenvolvimento.

@tyv Consegui investigar um pouco mais nos últimos dias... O Apple sandbox não permite network-bind fora dos contêineres do sandbox, mas não tenho certeza do que realmente fez com que seu aplicativo tivesse esse comportamento. Você já tentou criar sockets no seu código?

@jpittner Obrigado pela informação! Vou dar uma olhada nas últimas compilações do MAS.

@sethlu por sockets você também inclui websocket?

@sethlu

Você já tentou criar sockets no seu código?

tudo o que este aplicativo faz é alterar location.href para o https://... onde está o aplicativo da web e este aplicativo sim, abre a conexão do websocket.

@kof Sobre o web socket, a partir do texto network-bind Eu acho que não importa muito, desde que não toque em áreas críticas sobre a ligação essencialmente, eu acho?

Ligação à rede
Sintaxe: Ações: Filtros: Modificadores:
(ação network-bind [filtro] [modificador]) permitir negar
modo de arquivo de caminho de rede
enviar sinal sem registro
Definição:
Controle o acesso ao socket bind(). Não tem suporte para filtragem de IP, deve ser localhost ou * (verifique filtro de rede para mais informações).
Aplica-se a:
ligar, unp_bind
Exemplos):
(negar ligação de rede (ip local "*:7890"))
$ sandbox-exec -f ls2 nc -l 7890
nc: Operação não permitida
Saída de registro:
2 de setembro 21:08:41 macbox sandboxd[45438]: nc(45437) deny network-bind 0.0.0.0:7890

Ref: https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf

então talvez sejam os soquetes da web do domínio não localhost?

@tyv Você tentou adicionar com.apple.security.network.client no arquivo de direitos app(/parent)? Desculpe, não tenho certeza se pode funcionar, pois não encontrei casos semelhantes.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.network.client</key>
    <true/>
    <key>com.apple.security.application-groups</key>
    <string>Y8DPE6DGC7.com.ChatGrape</string>
  </dict>
</plist>

Vou tentar

Eu sou capaz de executar o aplicativo vazio após o sinal.
Tentará encontrar o que causa o problema e relatará de volta.

ok, eu encontrei o que mata o aplicativo quando ele é assinado
http://electron.atom.io/docs/all/#appmakesingleinstancecallback
shouldQuit === true neste exemplo do antigo documento oficial:

const shouldQuit = app.makeSingleInstance(() => {
  const {mainWindow} = state
  // Someone tried to run a second instance, we should focus our window
  if (mainWindow) showMainWindow()
  return true
})

if (shouldQuit) quit()

@sethlu é o mesmo com o novo trecho do documento

@tyv seu aplicativo funciona agora?

Eu removi esse código e sim, mas ainda não tive tempo de verificar o que há de errado com esse método
por que sempre retorna true quando o aplicativo é assinado

Em 7 de agosto de 2016, às 12h06, Zhuo Lu [email protected] escreveu:

@tyv seu aplicativo funciona agora?

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub ou silencie a conversa.

@tyv Alguns lugares em que acho que esse problema ocorre:

1. https://github.com/electron/electron/blob/91169396f6b631e823c5fe2c7a0865b41347f2c1/atom/browser/api/atom_api_app.cc#L426 -L431
2. https://github.com/electron/electron/blob/99ec841a8e4fe21182e2dfa7a1f085d70b80d6cf/chromium_src/chrome/browser/process_singleton_posix.cc#L881 -L902
3. https://github.com/electron/electron/blob/99ec841a8e4fe21182e2dfa7a1f085d70b80d6cf/chromium_src/chrome/browser/process_singleton_posix.cc#L740 -L754

Parece que o Electron abre um soquete e envia um singleton de processo de verificação de mensagens... Ainda não tenho certeza de como evitar que a ligação de rede seja endereçada na sandbox.

ok, entendo, então se isso não for corrigível, provavelmente comentar no guia é uma boa ideia.

ou o valor padrão deve ser false, e ainda comentar perto do método doc, seria bom

Por que isso não seria corrigível? É o nosso código - você pode registrar um bug separado?

@paulcbetts aqui está ^^^

Oi,
Não conserta, mesmo com um simples HelloWorld. Alguém tem uma ideia do que precisa ser feito para enviar meu aplicativo para a Mac Store (a compilação está funcionando bem quando não está assinando o aplicativo).

electron-packager . "MyApp" --platform=mas --arch=x64 --overwrite --version=1.4.4 --app-bundle-id="com.mycie.myapp" --app-version="1.0.0" --build-version="666"

electron-osx-sign "MyApp.app" --entitlements="mas.default.entitlements" --entitlements-inherit="mas.inherit.default.entitlements"

electron-osx-flat "MyApp"

mas.default.entitlements

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.network.client</key>
    <true/>
    <key>com.apple.security.network.server</key>
    <true/>
    <key>com.apple.security.application-groups</key>
    <string>XXXXXXXXXXX.com.mycie.myapp</string>
  </dict>
</plist>

mas.herdar.default.entitlements

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.inherit</key>
    <true/>
  </dict>
</plist>

electron-osx-sign:warn No `platform` passed in arguments, checking Electron platform... +0ms
  electron-osx-sign:warn No `identity` passed in arguments, discovering identities... +3ms
  electron-osx-sign Signing application... +1s
  electron-osx-sign > application         MyApp-mas-x64/MyApp.app +0ms
  electron-osx-sign > platform            mas +0ms
  electron-osx-sign > entitlements        ../mas.default.entitlements +0ms
  electron-osx-sign > child-entitlements  ../mas.inherit.default.entitlements +0ms
  electron-osx-sign > additional-binaries  +1ms
  electron-osx-sign > identity            3rd Party Mac Developer Application: BAYARD PRESSE (VE4JH2R5J4) +0ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper EH.app/Contents/MacOS/MyApp Helper EH +117ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper EH.app +130ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper NP.app/Contents/MacOS/MyApp Helper NP +120ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper NP.app +119ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper.app/Contents/MacOS/MyApp Helper +121ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/MyApp Helper.app +119ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework +122ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libffmpeg.dylib +1s
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libnode.dylib +152ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Frameworks/Electron Framework.framework +318ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/MacOS/MyApp +1s
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app/Contents/Resources/app/PepperFlashPlayer.plugin/Contents/MacOS/PepperFlashPlayer +599ms
  electron-osx-sign Signing... MyApp-mas-x64/MyApp.app +410ms
  electron-osx-sign Verifying sign... +612ms
  electron-osx-sign Verifying entitlements... +278ms
Application signed: MyApp-mas-x64/MyApp.app

Estou enfrentando esse problema, qual é a solução?
Quando
com.apple.security.app-sandbox está na minha lista - meu aplicativo fica em tela branca.