Azure DevOps

Azure Pipelines erstellt das Projekt mit dem .NET SDK, und das Paket Babel.Obfuscator fügt die Babel-Aufgabe in diesen Build ein. Auf dem Agent muss Babel nicht installiert sein: Das Paket bringt die Buildtools mit, und die Pipeline muss sich nur bei dem Feed authentifizieren, der es hostet, und Babel eine Lizenz übergeben.

Das Beispiel auf dieser Seite ist eine kleine Konsolenanwendung:

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

Das Paket in einem Azure-Artifacts-Feed hosten

Das Paket Babel.Obfuscator wird nicht auf nuget.org veröffentlicht. Sie erhalten es mit der Ultimate-Edition oder mit einer Standortedition von Babel Licensing. Laden Sie es in einen privaten Feed hoch, den nur Ihre Organisation lesen kann.

Öffnen Sie in Azure DevOps Artifacts, erstellen Sie einen Feed mit dem Namen Babel und laden Sie das Paket dorthin hoch:

dotnet nuget push Babel.Obfuscator.12.0.0.nupkg \
  --source "https://pkgs.dev.azure.com/ORGANISATION/_packaging/Babel/nuget/v3/index.json" \
  --api-key az

Legen Sie neben der Projektmappe eine Datei NuGet.config an, damit sowohl Ihr Rechner als auch der Buildagent das Paket aus diesem Feed auflösen:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="babel" value="https://pkgs.dev.azure.com/ORGANISATION/_packaging/Babel/nuget/v3/index.json" />
  </packageSources>
</configuration>

Anmeldedaten fehlen in dieser Datei absichtlich. Auf einem Entwicklerrechner fragt der Azure Artifacts Credential Provider  einmal danach. In der Pipeline liefert die Aufgabe NuGetAuthenticate das Token der Buildidentität. In beiden Fällen gelangt kein Geheimnis ins Repository.

Das Paket referenzieren

Fügen Sie die Paketreferenz jedem Projekt hinzu, dessen Assembly verschleiert werden soll:

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

PrivateAssets hält die Referenz aus den Paketen heraus, die Ihr Projekt erzeugt: Babel ist ein Tool für den Build und keine Abhängigkeit der ausgelieferten Assembly.

Die Lizenz als Geheimnis bereitstellen

Babel braucht eine Lizenz, um eine dauerhaft funktionierende Assembly zu erzeugen. Ohne Lizenz läuft es im Evaluierungsmodus, und die Ausgabe funktioniert nach kurzer Zeit nicht mehr.

Speichern Sie den Lizenzschlüssel stattdessen als geheime Variable. Fügen Sie in der Pipeline unter Variables die Variable BabelLicense hinzu und kennzeichnen Sie sie als geheim. Ordnen Sie sie dann im Buildschritt einer Umgebungsvariable zu und lesen Sie diese im Projekt aus:

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

Die Eigenschaft BabelLicense nimmt den Pfad einer Lizenzdatei, einen Lizenzschlüssel oder den Benutzerschlüssel einer Floating-Lizenz in der Form floating:<user key> an. Auf einem Buildagent sind die beiden letzten die richtige Wahl, weil keiner von ihnen eine Datei auf dem Datenträger braucht. Lokal bleibt die Eigenschaft ungesetzt, und Babel verwendet die Datei babel.licenses aus dem Projektordner oder einem übergeordneten Ordner. Die Entwickler arbeiten also ohne jede Pipelinekonfiguration weiter. Siehe Paketeinrichtung.

Die Pipeline

trigger:
  - main
 
pool:
  vmImage: ubuntu-latest
 
variables:
  buildConfiguration: Release
 
steps:
  - task: UseDotNet@2
    displayName: Install the .NET SDK
    inputs:
      version: 10.0.x
 
  - task: NuGetAuthenticate@1
    displayName: Authenticate to the Babel feed
 
  - script: dotnet restore DevOpsIntegration.sln
    displayName: Restore
 
  - script: dotnet build DevOpsIntegration.sln --configuration $(buildConfiguration) --no-restore
    displayName: Build and obfuscate
    env:
      BABEL_LICENSE: $(BabelLicense)
 
  - task: PublishPipelineArtifact@1
    displayName: Publish the obfuscated output
    inputs:
      targetPath: DevOpsIntegration/bin/$(buildConfiguration)/net10.0
      artifact: DevOpsIntegration

Zwei Einzelheiten verdienen einen Hinweis.

NuGetAuthenticate@1 macht den privaten Feed erreichbar. Die Aufgabe konfiguriert den Credential Provider mit der Identität der Pipeline selbst, sodass die Datei NuGet.config oben weder einen Abschnitt packageSourceCredentials noch ein Token von Ihnen braucht.

Geheime Variablen werden nicht automatisch an Skripte übergeben. Genau das ist der Sinn der Kennzeichnung als geheim. Erst der Block env: am Buildschritt gibt BabelLicense an den Prozess weiter, und er ist die einzige Stelle, an der der Schlüssel erscheint.

Die Verschleierung läuft als Teil von dotnet build. Einen eigenen Babel-Schritt gibt es nicht. Das Babel-Protokoll erscheint in der Buildausgabe, und ein Lizenz- oder Konfigurationsfehler lässt den Schritt fehlschlagen.

Die Verschleierung konfigurieren

Babel wird über MSBuild-Eigenschaften in der Projektdatei konfiguriert. Üblich ist, Debug-Builds unberührt zu lassen, damit sich das lokale Debuggen normal verhält, und Release-Builds zu schützen:

<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>
  <ResourceEncryption>true</ResourceEncryption>
</PropertyGroup>

Alle Eigenschaften sind in der Referenz des Pakets aufgeführt, und Verschleierung konfigurieren erklärt, welchen Funktionen von Babel sie entsprechen.

Für alles, was feiner ist als ein Schalter für die ganze Assembly, fügen Sie eine Regeldatei hinzu. Die folgende Regel hält die Kontrollflussverschleierung von kurzen Methoden fern, bei denen die Abflachung mehr kostet, als sie verbirgt:

<?xml version="1.0" encoding="utf-8" ?>
<Rules>
  <Rule name="reduce control flow" feature="control flow" exclude="false" applyToMembers="true">
    <Target>Classes,Structures</Target>
    <Pattern>*</Pattern>
    <Properties>
      <MaxSwitchTargets>5</MaxSwitchTargets>
      <MinInstructionCount>18</MinInstructionCount>
      <UseValueEncryption>false</UseValueEncryption>
    </Properties>
    <Description>Do not scramble methods with few instructions.</Description>
  </Rule>
</Rules>

Geben Sie dem Build die Datei mit der Eigenschaft BabelRules an:

<PropertyGroup>
  <BabelRules>$(MSBuildThisFileDirectory)babelRules.xml</BabelRules>
</PropertyGroup>

Das Ergebnis prüfen

Laden Sie das Pipelineartefakt herunter und prüfen Sie, ob die Assembly wirklich verschleiert ist, statt es nur anzunehmen. Das Beispiel Babel-Verschleierung erkennen zeigt, wie sich das automatisch testen lässt. Es lohnt sich, diese Prüfung als Kontrollpunkt in die Pipeline aufzunehmen: Sonst liefert eine falsch konfigurierte Lizenz oder ein übersprungener Buildschritt eine unverschleierte Assembly aus, ohne dass etwas fehlschlägt.

Bewahren Sie die vom Build erzeugte Map-Datei auf, wenn Sie Stacktraces aus der Produktion decodieren möchten. Siehe Stacktraces decodieren.