AppVeyor

Verschleiern Sie auf AppVeyor, indem Sie das NuGet-Paket von Babel Obfuscator im Feed Ihres AppVeyor-Kontos hosten und die Lizenz über eine sichere Variable übergeben.

AppVeyor erstellt die Projektmappe mit dem .NET SDK, und das Paket Babel.Obfuscator fügt diesem Build die Babel-Aufgabe hinzu. Wie bei jedem anderen Buildserver beschränkt sich die Arbeit auf zwei Dinge: Der Agent muss den privaten Feed mit dem Paket erreichen, und Babel braucht eine Lizenz, ohne dass sie ins Repository geschrieben wird.

Das Beispiel auf dieser Seite ist eine kleine Konsolenanwendung:


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

Das Paket in den AppVeyor-Feed hochladen

Jedes AppVeyor-Konto hat einen eigenen NuGet-Feed. Kopieren Sie unter Account Settings > NuGet die URL des Feeds und den API-Schlüssel, und laden Sie dann das Paket hoch:


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

Der Feed des Kontos ist privat, aber er ist das Einzige, was zwischen dem Paket und dem Internet steht. Laden Sie Babel.Obfuscator niemals auf nuget.org oder in einen Feed außerhalb Ihrer Organisation hoch.

Registrieren Sie denselben Feed als Paketquelle, damit die Projektmappe auf einem Entwicklerrechner und auf dem Buildagent auf gleiche Weise wiederhergestellt wird:

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>

Tragen Sie die Anmeldedaten des Feeds nicht in diese Datei ein, und übergeben Sie sie in appveyor.yml nicht auf einer Befehlszeile mit nuget sources add. Beides landet im Repository, und ein Passwort in einem öffentlichen Repository ist ein Passwort, das gelesen wurde. Verwenden Sie die verschlüsselten Variablen von AppVeyor, wie unten gezeigt.

Verschlüsseln Sie das Passwort des Feeds unter Account Settings > Encrypt YAML und verweisen Sie dann in der Buildkonfiguration auf den verschlüsselten Wert. AppVeyor entschlüsselt ihn nur für Builds Ihres eigenen Repositorys und nie für Pull Requests aus Forks.

Das Paket referenzieren

AppVeyorIntegration.csproj


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

Mehr als die Referenz auf das Paket ist nicht nötig: Die Babel-Aufgabe wird in den Build eingefügt und verschleiert die Ausgabe-Assembly des Projekts. Schon ein lokaler Build erzeugt eine verschleierte Ausgabe, und das Babel-Protokoll erscheint in der Buildausgabe. Das ist der richtige Moment, die Konfiguration zu prüfen, noch bevor der Buildserver überhaupt ins Spiel kommt.

Die Lizenz bereitstellen

Fügen Sie den Lizenzschlüssel unter Settings > Environment als sichere Variable mit dem Namen BABEL_LICENSE hinzu und lesen Sie ihn dann in der Projektdatei aus:

AppVeyorIntegration.csproj


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

Durch die Bedingung arbeiten Entwicklerrechner unverändert weiter: Ist die Variable nicht gesetzt, greift Babel auf die Datei babel.licenses im Projektordner oder in einem übergeordneten Ordner zurück. BabelLicense nimmt auch den Benutzerschlüssel einer Floating-Lizenz in der Form floating:<user key> an. Das ist die bessere Wahl, wenn sich mehrere Buildagents eine Lizenz teilen. Siehe Paketeinrichtung.

Wer babel.licenses in das Repository aufnimmt, wie es ältere Anleitungen empfahlen, legt die Lizenz für jeden offen, der das Repository lesen oder forken kann. Das spätere Löschen der Datei macht die Offenlegung nicht rückgängig: Der Blob bleibt in jedem Fork und im Verlauf des Repositorys selbst erreichbar.

Die Buildkonfiguration

Die Datei appveyor.yml im Stammverzeichnis des Repositorys ersetzt alles, was in der Oberfläche von AppVeyor konfiguriert ist:

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

Das Image Visual Studio 2022 enthält aktuelle .NET SDKs. Fügen Sie einen Schritt mit dotnet-install nur hinzu, wenn Sie ein SDK brauchen, das im Image fehlt. Die Verschleierung findet innerhalb von dotnet build statt. Es ist also kein Babel-Schritt hinzuzufügen, und ein Lizenzfehler lässt den Build fehlschlagen.

Der Block artifacts sammelt die Buildausgabe in einer Zip-Datei, die auf der Registerkarte Artifacts veröffentlicht wird. So können Sie die verschleierte Assembly herunterladen und untersuchen.

--store-password-in-clear-text schreibt das Passwort des Feeds in die Datei NuGet.config des Agents. Auf einer kurzlebigen Build-VM, die nach dem Build zerstört wird, ist das vertretbar. Es ist aber der Grund, warum dieser Befehl niemals auf einem Entwicklerrechner ausgeführt werden darf.

Die Verschleierung konfigurieren

Die Einstellungen von Babel sind MSBuild-Eigenschaften. Sie werden je Konfiguration angewendet, damit das Debuggen unberührt bleibt:

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>

Die vollständige Liste steht in der Referenz des Pakets, und Verschleierung konfigurieren beschreibt, was jede Eigenschaft bewirkt. Ist eine Einstellung für die ganze Assembly zu grob, grenzt eine Datei mit Verschleierungsregeln sie auf die Typen und Member ein, auf die es ankommt.

Das Ergebnis prüfen

Laden Sie das Artefakt herunter und überzeugen Sie sich, dass die Assembly verschleiert ist, statt es nur anzunehmen. Das Beispiel Babel-Verschleierung erkennen automatisiert diese Prüfung. Im Build ausgeführt, macht es aus einer stillschweigend unverschleierten Version einen fehlgeschlagenen Build.