AppVeyor

Offusca su AppVeyor ospitando il pacchetto NuGet di Babel Obfuscator sul feed del tuo account AppVeyor e passando la licenza tramite una variabile sicura.

AppVeyor compila la soluzione con l’SDK .NET, e il pacchetto Babel.Obfuscator aggiunge il task Babel a quella build. Come per qualsiasi altro server di build, il lavoro si riduce a due cose: permettere all’agente di raggiungere il feed privato che contiene il pacchetto e fornire a Babel una licenza senza scriverla nel repository.

L’esempio usato in questa pagina è una piccola applicazione console:


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

Caricare il pacchetto sul feed di AppVeyor

Ogni account AppVeyor ha un proprio feed NuGet. Da Account Settings → NuGet copia l’URL del feed e la chiave API, poi carica il pacchetto:


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

Il feed dell’account è privato, ma è l’unica cosa che separa il pacchetto da internet. Non caricare mai Babel.Obfuscator su nuget.org né su alcun feed esterno alla tua organizzazione.

Registra lo stesso feed come origine pacchetti, così la soluzione viene ripristinata allo stesso modo su un computer di sviluppo e sull’agente di 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>

Non inserire le credenziali del feed in questo file e non passarle in una riga di comando nuget sources add in appveyor.yml. In entrambi i casi finiscono nel repository, e una password in un repository pubblico è una password che qualcuno ha già letto. Usa le variabili cifrate di AppVeyor, come indicato sotto.

Cifra la password del feed con Account Settings → Encrypt YAML, poi fai riferimento al valore cifrato dalla configurazione di build. AppVeyor lo decifra solo per le build del tuo repository, e mai per le pull request provenienti dai fork.

Aggiungere il riferimento al pacchetto

AppVeyorIntegration.csproj


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

Aggiungere il riferimento al pacchetto è tutto ciò che serve: il task Babel viene inserito nella build e offusca l’assembly di output del progetto. Già la build in locale produce un output offuscato e il log di Babel compare nell’output della build: è il momento giusto per controllare la configurazione, prima ancora di coinvolgere il server di build.

Fornire la licenza

Aggiungi la chiave di licenza come variabile sicura in Settings → Environment, con il nome BABEL_LICENSE, poi leggila dal file di progetto:

AppVeyorIntegration.csproj


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

La condizione lascia invariato il funzionamento sui computer di sviluppo: se la variabile non è impostata, Babel ripiega sul file babel.licenses che trova nella cartella del progetto o in una cartella superiore. BabelLicense accetta anche la chiave utente di una licenza flottante scritta come floating:<user key>, che è la scelta migliore quando più agenti di build condividono una sola licenza. Vedi Configurazione del pacchetto.

Aggiungere babel.licenses al repository, come suggerivano le guide meno recenti, espone la licenza a chiunque possa leggerlo o crearne un fork. Eliminare il file in seguito non annulla l’esposizione: il blob resta raggiungibile in ogni fork e nella cronologia del repository stesso.

La configurazione di build

Il file appveyor.yml nella radice del repository sostituisce tutto ciò che è configurato nell’interfaccia di 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’immagine Visual Studio 2022 include gli SDK .NET correnti; aggiungi un passo dotnet-install solo se ti serve un SDK che l’immagine non contiene. L’offuscamento avviene all’interno di dotnet build, quindi non c’è alcun passo Babel da aggiungere e un errore di licenza fa fallire la build.

Il blocco artifacts raccoglie l’output della build in un file zip pubblicato nella scheda Artifacts, così puoi scaricare l’assembly offuscato ed esaminarlo.

--store-password-in-clear-text scrive la password del feed nel file NuGet.config dell’agente. È accettabile su una macchina virtuale di build usa e getta, che viene distrutta al termine della build, ma è il motivo per cui questo comando non deve mai essere eseguito su un computer di sviluppo.

Configurare l’offuscamento

Le impostazioni di Babel sono proprietà MSBuild, applicate per configurazione in modo da lasciare intatto il debug:

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>

L’elenco completo è in Riferimento del pacchetto; Configurazione dell’offuscamento spiega che cosa fa ciascuna proprietà. Quando un’impostazione valida per l’intero assembly è troppo grossolana, un file di regole di offuscamento la restringe ai tipi e ai membri che contano.

Verificare il risultato

Scarica l’artefatto e accertati che l’assembly sia offuscato invece di darlo per scontato: l’esempio Rilevare l’offuscamento Babel automatizza questo controllo, ed eseguirlo nella build trasforma un rilascio rimasto silenziosamente non offuscato in una build fallita.