Este artigo explica uma maneira de assinar os códigos dos seus
aplicativos internos, juntamente com seus instaladores. A assinatura de
código de seus aplicativos e instaladores fornece uma experiência de
usuário amigável do UAC durante a instalação, desinstalação, e quando os
aplicativos legados podem precisar ser executados com privilégios
administrativos (mais sobre privilégios administrativos abaixo).
Experiência de instalação amigável do UAC
A imagem abaixo mostra uma caixa de diálogo UAC amigável, completo
com o nome do Programa, Verifiedpublisher. Se os seus aplicativos
internos não são de código assinado, o usuário receberá um diálogo de
aviso, com um nome de programa bizarro, e Verifiedpublisher será
definido para desconhecido.
Eu não sei quanto a você, mas eu prefiro dar condição aos meus
usuários para ver diálogos UAC amigáveis, em vez do diálogo de aviso. De
repente, eles aprovaram “acidentalmente” um aviso UAC que pode causar
um grande problema.
Se você está assinando aplicativos que não são internos para a sua
organização, o conteúdo ao redor dos certificados e a orientação em
torno de signtool.exe podem violar as regras de assinatura de código de
organizações ou dos procedimentos.
Este artigo fala sobre a assinatura de código de aplicativos internos que serão utilizados na sua organização.
Certificado de assinatura de código
A primeira ordem de um negócio é obter um certificado de assinatura
de código instalado em máquinas que vão construir seus aplicativos
internos. Você pode notar na imagem abaixo que o meu servidor de
certificado gmcx-Security-CA emitiu um certificado de assinatura de
código e que o importei para a loja “Personal” no âmbito da pasta
“Certificates”.
Para ser honesto, a criação de um certificado de assinatura de código
exigiu a criação de um template de certificado no servidor de
certificado que me permitiu fazer isso. Eu achei este artigo do TechNet
muito útil:
http://technet.microsoft.com/en-us/library/cc731705(v=ws.10).aspx
Depois de criar o certificado, exporte-lo e imporeá-lo em todas as máquinas sob os usuários “Personal” armazenados como acima.
Por exemplo, eu tenho esse certificado instalado nas máquinas dos nossos desenvolvedores e dois no servidor de build.
Configurando a solução (projetos executáveis)
Existem várias maneiras de configurar as ações que ocorrem durante
MSBuilds. Eu escolhi o método do “arquivo batch” por ele ser muito fácil
de implementar e depurar. Você pode aproveitar um dos dois métodos não
convencionais e construir tarefas ou criar a sua própria tarefa de
compilação, mas eu escolhi “arquivos batch”, pelas razões acima.
Observe que verifiquei esses arquivos batch em controle de versão.
Isso garante que todas as máquinas podem construir a solução
corretamente.
AfterBuildTasksDebug.bat
Se o cenário requer que você faça uma assinatura de código da
compilação de depuração, o arquivo batch abaixo usa o programa
signtool.exe para a assinatura do código do programa .exe. Você
“poderia” também passar parâmetros de linha de comando para o arquivo
batch que inclui o nome da pasta do alvo, juntamente com o nome do alvo.
Preferi manter isso de uma forma simples para fazer com que ficasse
mais fácil de entender todas as partes.
Observe que eu não tinha que especificar um certificado, uma senha
etc. Isso porque eu só tenho um certificado de assinatura de código
instalado na minha máquina. O switch “/a” instrui signtool a escolher
automaticamente o código de certificado de assinatura de minha store
“Personal”.
@echo on
call “C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat”
call signtool sign /a “C:\Projects\GMC\Src\GMC\bin\Debug\GMC.exe”
AfterBuildTasksRelease.bat e a pegadinha
Agora um tempo para uma pegadinha desagradável. Ela fez com que eu
gastasse cerca de duas horas tentando descobrir por que cada vez que eu
fazia uma compilação de lançamento utilizando o projeto de instalação
para construir e criar o pacote de instalação que o instalador do .exe
instalou não estava mais assinado.
Leia este tópico no Dev Center do Windows para obter mais detalhes: Setup project strips digital signature from exe target.
Agora que você já leu o tópico acima, vai compreender por que, ao
criar um release build, você deve assinar o código de .exe nas pastas
\obj e \bin.
O SignTool… controla a assinatura do meu exe. Deixe-me chamar um
interruptor signtool adicional que você precisa ter em mente quando
assinar o seu .exe.
Você também deve especificar o switch “/ t”. Isso colocará data e
hora em seu .exe para que o usuário saiba quando o .exe foi construído.
@echo on
call “C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat”
call signtool sign /a /t http://timestamp.comodoca.com/authenticode
“C:\Projects\GMC\Src\GMC\obj\Release\GMC.exe”
call signtool sign /a /t http://timestamp.comodoca.com/authenticode
“C:\Projects\GMC\Src\GMC\bin\Release\GMC.exe”
Configurando o Visual Studio 2010 para usar os arquivos batch acima durante uma compilação
- Abra a caixa de diálogo Build Events na guia das propriedades do projeto .exe.
- Altere o “Executar o evento pós-compilação” para “Quando o compliador atualizar a saída do projeto”.
- Digite o texto acima na caixa de texto “pós-evento de compilação de linha de comando”.
Isso irá executar um dos dois arquivos batch com base na configuração, Debug ou Release.
Construindo a solução
Como muitos de vocês, eu não construí o meu Release Build dentro do
Visual Studio. Alguns usam um servidor de build, outros os constroem a
partir da linha de comando para permitir que outras tarefas sejam
realizadas.
Logo abaixo está um fragmento de um arquivo batch que gosto de usar
quando estou construindo um release build. O comando …devenv..
reconstrói a minha solução. Observe o switch “/rebuild” em vez do switch
“/build”.
O comando signtool … assina o meu instalador .msi que o projeto Setup
construiu. Deixe-me chamar dois switches signtool adicionais com os
quais você precisa se importar.
É importante que você especifique o switch “/d” para seus
instaladores .msi. Se você voltar até o topo deste artigo e olhar a
imagem UAC, verá que o nome do programa corresponde ao texto do switch
“/d” abaixo. Se você não especificar isso, o usuário verá um texto
bizarro.
Você também deve especificar o switch “/t” . Isso irá colocar data e
hora em seu instalador para que o usuário saiba quando o instalador foi
construído.
@echo on
call “C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat”
devenv /rebuild Release /project GMC_Setup C:\Projects\GMC\Gmc.sln
echo .
echo .
pause
signtool sign /a /d “GMC for Office 2010 Setup” /t http://timestamp.comodoca.com/authenticode
C:\Projects\GMC\Src\GMC_Setup\Release\GMCForOffice2010_Setup.msi
… additional tasks
Aplicativos legados que rodam no Windows 7 e superiores
Minha empresa possui um aplicativo legado Windows Forms que foi
escrito durante a época do Windows XP. Minha empresa, como muitas
outras, nunca instalou o Windows Vista. Recentemente, o Windows 7 foi
instalado em nossos desktops corporativos.
Bem, os aplicativos legados da empresa que eu herdei fazem coisas que
não são amigáveis. Por exemplo, escrever para a pasta \Arquivos de
Programas e outras tarefas que são agora consideradas tabu para o
Windows 7.
Sendo um bom administrador de empresa e desenvolvedor, quero todos os
meus clientes executando o Windows 7 com o UAC com a configuração
padrão e que meus usuários aprendam sobre o recurso UAC e seus
benefícios; isso irá proporcionar-lhes um ambiente de computação mais
seguro aqui no trabalho e em casa.
A Microsoft documentou UAC aqui: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511445.aspx
A Microsoft e os blogueiros têm documentado uma série de estratégias
para lidar com aplicativos UAC e legados. Transformar o UAC ou limitar
as suas capacidades não devem ser consideradas boas opções.
Eu não estava disposto a correr o risco de modificar nossos
aplicativos legados, então executei meus poucos aplicativos empresariais
com um manifesto de aplicativo incorporado que diz ao sistema
operacional que esse aplicativo requer privilégios de administrador para
ser executado. Todos os nossos usuários são administradores em seus
computadores locais.
Exemplo de manifesto do aplicativo
Observe o manifesto do aplicativo abaixo que o “requestExecutionLevel” é “requireAdministrator”.
<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<assembly xmlns=”urn:schemas-microsoft-com:asm.v1″ manifestVersion=”1.0″>
<assemblyIdentity version=”1.0.0.0″ processorArchitecture=”X86″ name=”GMC” type=”win32″/>
<trustInfo xmlns=”urn:schemas-microsoft-com:asm.v3″>
<security>
<requestedPrivileges>
<requestedExecutionLevel level=”requireAdministrator”/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Para incorporar o manifesto do aplicativo acima, você precisa usar o
programa mt.exe. Eu coloquei o comando abaixo no topo dos meus dois
arquivos batch, AfterBuildTasksDebug.bat e AfterBuildTasksRelease.bat.
Você vai precisar editar os caminhos e o nome .exe, bem como o nome do manifesto.
call “C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\mt.exe” -manifest
“C:\Projects\GMC\Src\GMC\GMC.exe.manifest”
-outputresource:”C:\Projects\GMC\Src\GMC\bin\Debug\GMC.exe;#1″
Fechamento
Para aqueles que têm a necessidade ou desejo de assinar os códigos de
seus aplicativos empresariais internos, espero que este artigo tenha
ajudado a evitar a longa curva de aprendizado.
Tenha um ótimo dia!
***
Texto original disponível em http://karlshifflett.wordpress.com/2012/04/16/coding-signing-internal-applications-and-a-gotcha/
25
0
