AppVeyor

Obfusquez sur AppVeyor en hébergeant le package NuGet Babel Obfuscator dans le flux de votre compte AppVeyor et en transmettant la licence dans une variable sécurisée.

AppVeyor génère la solution avec le SDK .NET, et le package Babel.Obfuscator ajoute la tâche Babel à ce build. Comme sur tout autre serveur de build, le travail se limite à deux choses : permettre à l’agent d’atteindre le flux privé qui contient le package, et fournir une licence à Babel sans l’écrire dans le dépôt.

L’exemple utilisé sur cette page est une petite application console :


git clone https://github.com/babelfornet/appveyor-integration.git

Importer le package dans le flux AppVeyor

Chaque compte AppVeyor possède son propre flux NuGet. Dans Account Settings > NuGet, copiez l’URL du flux et la clé API, puis envoyez-y le package :


dotnet nuget push Babel.Obfuscator.12.0.0.nupkg \
  --api-key APPVEYOR_API_KEY \
  --source https://ci.appveyor.com/nuget/ACCOUNT/api/v2/package

Le flux du compte est privé, mais il est la seule barrière entre le package et Internet. N’envoyez jamais Babel.Obfuscator sur nuget.org ni sur un flux extérieur à votre organisation.

Déclarez le même flux comme source de packages afin que la solution soit restaurée de la même façon sur une machine de développement et sur l’agent de build :

NuGet.config


<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="appveyor" value="https://ci.appveyor.com/nuget/ACCOUNT/api/v2" />
  </packageSources>
</configuration>

Ne placez pas les identifiants du flux dans ce fichier, et ne les passez pas sur une ligne de commande nuget sources add dans appveyor.yml. Dans les deux cas, ils finissent dans le dépôt, et un mot de passe placé dans un dépôt public est un mot de passe qui a été lu. Utilisez les variables chiffrées d’AppVeyor, comme ci-dessous.

Chiffrez le mot de passe du flux avec Account Settings > Encrypt YAML, puis référencez la valeur chiffrée dans la configuration du build. AppVeyor ne la déchiffre que pour les builds de votre propre dépôt, et jamais pour les pull requests issues de forks.

Référencer le package

AppVeyorIntegration.csproj


<ItemGroup>
  <PackageReference Include="Babel.Obfuscator" Version="12.0.0">
    <PrivateAssets>all</PrivateAssets>
    <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
  </PackageReference>
</ItemGroup>

Il suffit de référencer le package : la tâche Babel est injectée dans le build et obfusque l’assembly de sortie du projet. Un build local produit déjà une sortie obfusquée, et le journal de Babel apparaît dans la sortie du build. C’est le bon moment pour vérifier la configuration, avant même de faire intervenir le serveur de build.

Fournir la licence

Ajoutez la clé de licence comme variable sécurisée dans Settings > Environment, sous le nom BABEL_LICENSE, puis lisez-la depuis le fichier de projet :

AppVeyorIntegration.csproj


<PropertyGroup Condition="'$(BABEL_LICENSE)' != ''">
  <BabelLicense>$(BABEL_LICENSE)</BabelLicense>
</PropertyGroup>

Grâce à la condition, les machines de développement fonctionnent sans changement : lorsque la variable n’est pas définie, Babel se rabat sur le fichier babel.licenses trouvé dans le dossier du projet ou dans un dossier parent. BabelLicense accepte aussi une clé utilisateur de licence flottante, écrite sous la forme floating:<user key>, ce qui est préférable lorsque plusieurs agents de build partagent une même licence. Voir Configuration du package.

Ajouter babel.licenses au dépôt, comme le suggéraient d’anciens guides, expose la licence à toute personne qui peut lire le dépôt ou en créer un fork. Supprimer le fichier par la suite n’annule pas cette exposition : le blob reste accessible dans chaque fork et dans l’historique du dépôt lui-même.

La configuration du build

appveyor.yml, à la racine du dépôt, remplace tout ce qui est configuré dans l’interface d’AppVeyor :

appveyor.yml


version: '1.0.{build}'
image: Visual Studio 2022
 
branches:
  only:
    - main
 
configuration: Release
 
environment:
  feed_user: ACCOUNT
  feed_password:
    secure: <paste the value produced by Encrypt YAML>
 
install:
  - ps: dotnet nuget update source appveyor --username $env:feed_user --password $env:feed_password --store-password-in-clear-text
 
before_build:
  - ps: dotnet restore AppVeyorIntegration.sln
 
build_script:
  - ps: dotnet build AppVeyorIntegration.sln --configuration $env:CONFIGURATION --no-restore
 
artifacts:
  - path: AppVeyorIntegration\bin\$(configuration)\net10.0
    name: Build_$(configuration)_$(appveyor_build_version)
    type: zip

L’image Visual Studio 2022 fournit des SDK .NET récents ; ajoutez une étape dotnet-install uniquement si vous avez besoin d’un SDK que l’image ne contient pas. L’obfuscation a lieu dans dotnet build : il n’y a donc aucune étape Babel à ajouter, et un échec lié à la licence fait échouer le build.

Le bloc artifacts rassemble la sortie du build dans une archive zip publiée sous l’onglet Artifacts, ce qui vous permet de télécharger l’assembly obfusqué et de l’examiner.

--store-password-in-clear-text écrit le mot de passe du flux dans le NuGet.config de l’agent. C’est acceptable sur une machine virtuelle de build jetable, détruite à la fin du build, mais c’est la raison pour laquelle cette commande ne doit jamais être exécutée sur une machine de développement.

Configurer l’obfuscation

Les paramètres de Babel sont des propriétés MSBuild, appliquées par configuration afin de ne rien changer au débogage :

AppVeyorIntegration.csproj


<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
  <BabelEnabled>false</BabelEnabled>
</PropertyGroup>
 
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
  <StringEncryption>stream</StringEncryption>
  <ControlFlowObfuscation>if=on;goto=on;switch=on;case=on;call=on</ControlFlowObfuscation>
  <ControlFlowIterations>3</ControlFlowIterations>
</PropertyGroup>

La liste complète se trouve dans Référence du package ; Configurer l’obfuscation décrit le rôle de chaque propriété. Lorsqu’un paramètre appliqué à tout l’assembly est trop grossier, un fichier de règles d’obfuscation le restreint aux types et aux membres qui comptent.

Vérifier le résultat

Téléchargez l’artefact et vérifiez que l’assembly est obfusqué au lieu de le supposer : l’exemple Détecter l’obfuscation Babel automatise ce contrôle. Exécuté pendant le build, il fait échouer ce dernier au lieu de laisser sortir, sans que rien le signale, une version non obfusquée.