J'ai un authentrice certificat (.pfx) que j'utilise pour signer des exécutables.
Comment puis-je configurer Construire l'équipe afin qu'il signe chaque exécutable (.exe , .dll, ...) automatiquement tout en construisant le projet?
4 Réponses :
ne pas.
Vous ne souhaitez pas signer automatiquement des constructions. La plupart des constructions n'ont pas besoin de signature de toute façon; Ils sont utilisés uniquement pour automatiser les tests. Certaines constructions peuvent être remises à vos testeurs internes. Mais construit uniquement que vous libérez réellement en dehors de votre organisation, il faut des signatures authenticodes.
Dans ce cas, vous devriez avoir une étape de vérification manuelle après sa signature. Donc, la signature manuellement n'insère pas d'une étape manuelle supplémentaire dans le processus de libération et l'automatisation de l'automatisation économise de très peu de temps. En échange, il y aura beaucoup moins de fichiers signés flottant dans votre organisation et vous pouvez faire des garanties beaucoup plus fortes sur les fichiers qui sont.
Cela semble raisonnable de ne pas signer tout chaque fois. Cependant, nous devons établir un processus automatisé pour signer la version de version du logiciel. De plus, pour la vérification via un test de plate-forme pour Microsoft, chaque .exe, .dll et .msi doit être signé. Nous avons un processus automatisé qui obtient les sources actuelles, les versions automatiques, les construit, crée des licences et une structure de répertoire, tout emballage dans les MSIS, met en place des documents dans les dossiers et enfin de zips tout pour la distribution. Nous ajouterions simplement un autre script de construction (MS Build -> Build-Team) pour la pièce de signature. Mais comment?
Oh, j'accepte que vous devriez signer la version de version. Et je suis d'accord avec un processus surtout automatisé. Il suffit de mettre une invite de pause dans le processus de libération, avant d'emballer les fichiers binaires dans le MSI. À ce stade, vous pouvez facilement signer les fichiers binaires que vous souhaitez signé. Ils sont tous créés à ce stade, il est donc facile de les faire référence à une boucle pour boucle ou éventuellement juste une base générique.
Je ne suis pas d'accord sur "ne pas déranger" de signer. Nous expédions plus de 100 assemblys signés dans notre produit et ils sont emballés dans un programme d'installation qui est également signé. Ne pas automatiser ce serait la folie. Il vaut bien mieux tester votre produit de libération réelle que quelque chose de "semblable", et il est plus sûr si tous vos installateurs sont obscurcissés et signés de sorte qu'une copie non protégée ne puisse pas fuir à la nature. Nous exécutons également un magasin agile, donc n'importe quelle construction (c'est bien) est potentiellement une libération. (Nous ne signerons pas notre construction CI cependant, mais cela ne produit pas d'exe qui est réellement utilisé pour quoi que ce soit)
De toute évidence, vous pourrez outiller votre processus de libération tel que la signature des 100 assemblages est une étape manuelle unique. Mais cela fait partie du processus de libération, pas du processus de construction.
Je ne suis pas d'accord. Le code doit être signé à chaque étape, y compris des constructions non libérées. Créez un certificat de test, sinon vous ne pouvez pas vérifier le comportement de l'authentification sur vos systèmes. Considérez .NET, où les assemblages d'authentification se comportent différemment. Nous avons eu l'une de nos applications qui sont extrêmement gravement pour les utilisateurs de modem en raison de la recherche de la liste de révocation lors de «la collecte de preuves». Vous déclarez également que les assemblées doivent être signées pendant le «processus de libération». Dans le cas d'un installateur, il faudrait désassembler l'installateur, signé, puis réassemblé. Insensé.
Désolé, mais votre réponse n'a pas de sens. Pourquoi auriez-vous besoin de désassembler un installateur? Comme l'exécutable, il est construit dans le cadre du processus de libération. L'exécutable est signé, ajouté à l'installateur, puis le programme d'installation est construit. (Le processus de libération comprend nécessairement la construction de l'exécutable à partir d'un état étiqueté de contrôle de la source, afin d'activer la reproducabilité. Donc, toutes les étapes suivantes font également partie du processus de libération.)
Je ne suis pas d'accord. Étant donné que le certificat de signature de code doit être installé sur l'ordinateur de construction afin d'exécuter la signature, pourquoi ne pas signaler tout ce qui est construit sur cet ordinateur chaque fois qu'il est construit? L'ordinateur est "à risque" car il dispose du certificat de signature de code installé, il faudra donc être protégé de manière protégée de la manière (sécurité physique et sécurité du système). Si elle est protégée, pourquoi ne pas le laisser faire le travail qu'il était destiné à faire, préparez les fichiers de livraison, de manière cohérente, à chaque fois?
Malheureusement, la réponse "NE" semble également être la standard de réponse Microsoft, car elles semblent ne fournir presque aucun support dans Msbuild pour boucler une liste de noms de fichiers, appeler un programme une fois pour chaque nom de fichier dans la liste. J'ai trouvé des moyens de transmettre une liste de fichiers généralisée de caractères génériques dans le programme SignTool.exe, mais il ne peut que gérer un fichier à la fois.
Je crains (pour moi) qu'il est de retour à la rédaction d'un fichier de commandes qui boucle sur ses arguments et appelle SignTool pour chaque argument. Écrire des fichiers par batch pour la tâche commune de la signature d'une sortie de construction me fait penser que Msbuild n'est vraiment pas aussi mature un système de construction tel qu'il devrait être. Soit cela, ou SignTool a la mauvaise interface. Dans les deux cas, la signature de plusieurs fichiers sans énumérer le nom de chaque fichier à la signer semble être un "non go" avec Msbuild.
J'ai trouvé une façon de laisser SignTool itéralement sur une liste de fichiers d'une équipe d'équipe. Étant donné qu'il doit être fait au niveau de la solution, le seul inconvénient est que vous devez avoir besoin de filtre Spéficy un filtre pour inclure / à l'exclusion des fichiers (par exemple, vous ne souhaitez pas signer des bibliothèques 3ème partie et vous ne voudriez que inclure les fichiers EXE et DLL) . Je vous intéresse, je peux poster des indications sur notre blog de développement (qui est l'allemand ...)
Je serais intéressé par votre méthode d'itération de SignTool sur une liste de fichiers et je suis heureux de le lire en allemand.
Nous utilisons simplement un fichier de commandes que nous
Je ne sais pas si les choses ont changé à Msbuild depuis 2009, mais vous pouvez certainement boucler dans une liste de fichiers et exécuter un outil pour chaque fichier de la liste. Vous recherchez Batching de tâche .
Voici la méthode que nous utilisons:
Déchargez le projet WIX et sélectionnez Modifier
Faites défiler vers le bas, où vous pouvez trouver Ajouter une nouvelle ligne immédiatement au-dessus de celui-ci: Créer un nouveau fichier XML nommé projetName.custom.Targets et placez le code suivant dans:
Créer un certificat d'authentification test (nous nomma Nos nôhno authenticodetest.pfx) et placez-le dans le contrôle de la source - le chemin d'accès à celui-ci est défini dans la propriété authenticodecertfile. Pour le tester, exécutez MSBuild à la ligne de commande et modifiez la propriété Posturière - c'est-à-dire / msbuild Test.sln / p: surpasser = C: \ Test Certaines personnalisations seront nécessaires si: < ul>
Pour exécuter votre version finale Build Select "Neuf Build Build" dans TFS. Cliquez sur "Paramètres" et développez "Avancé". Sous "Arguments Msbuild" Ajouter /p:AuthentiCodecertFile=ProductionCertfile.pfx / p: authenticodepassword = secret . Notez que cela peut ne pas être entièrement sécurisé - il pourrait être délicat d'avoir l'agent de construction trouver le fichier PFX sans le vérifier et le mot de passe pourrait être connecté dans la sortie de la version. Vous pouvez alargiment que vous pouvez créer un agent de construction en mode verrouillé spécial pour cela, ou exécuter la construction localement à la ligne de commande - mais évidemment, ce ne serait pas un environnement "chambre propre". Il peut être utile de créer un serveur "nettoyal" verrouillé spécialement à cette fin.
Un moyen d'éviter d'avoir le mot de passe dans texte simple dans le fichier de projet / msbuild est décrit dans la question de la pile de dépassement Comment puis-je stocker en toute sécurité un mot de passe .pfx à utiliser dans Msbuild? . Essentiellement, il utilise le magasin de certificats Windows et l'option / SHA1 pour SignTool.exe . La sécurité est ensuite liée au compte d'utilisateur qui doit avoir un magasin de certificats avec le certificat en question.
Ma réponse s'appuie sur la réponse de Shadowchaser. La différence que mon objectif Msbuild signera un fichier spécifié ou si aucun n'est spécifié, il signera la sortie de construction du projet à partir de laquelle la cible a été invoquée.
Enregistrez les éléments suivants dans un fichier cibles disons signature.custom.targets. Une fois que vous l'enregistrez, incluez-la simplement dans votre CSPROJ ou WixProj et utilisez la cible pour signer votre sortie. Cela fonctionnera également sur la machine de développement local en tant que signe.properties (c'est un hybride dev Env puis nous ne voulions pas spécifier deux fois les propriétés du certificat) Le fichier n'existe pas sur la boîte de développement locale. p>
Pour signer un fichier à partir de la ligne de commande à l'aide de cette option, vous pouvez P>
<Import Project="$(SolutionDir)signing.custom.targets" /> <Target Name="AfterBuild" DependsOnTargets="SignAssembly"> </Target>
Une DLL est un assemblage, pas un exécutable. Un EXE est un assemblage exécutable. Donc, vous voulez vraiment savoir comment signer des assemblages, pas les exécutables. La différence de mots clés pourrait aider - ne peut pas dire que je sais beaucoup de la signature, cependant.
Dans l'équité à l'OP - MS, utilisez le terme "exécutable (.exe, .dll ...)" dans les programmes de logo Windows.
De plus, les DLL et les exes natifs / non gérés ne sont pas des assemblages. Les assemblages d'ex-exes et de DLL sont une terminologie spécifique .NET et s'applique uniquement à CLI. Les DLL non gérés ne peuvent pas aller dans le GAC et ne peuvent pas être signés par le nom fort, mais ils peuvent être authenticodes signés. Ref: Assemblage CLI, Wikipedia