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/