Diese Seite ist eine Übersetzung der englischen Dokumentation. Befehle, Bezeichner und Beispiele bleiben unverändert. Runtime 7.24.4 · SDK 2.6.7. Englische Fassung

Integrität der Windows-Laufzeit und Antivirus-Meldungen

Status: Aktueller Quellstand; Release-Qualifikation ausstehend Umfang: Installation der Windows-CLI, Prüfung von Aktualisierungen und Betreiberdiagnosen Zuletzt geprüft: 2026-09-17 Verantwortlich: Betreuer der AX-Code-Laufzeit

AX Code verwendet getrennte Kontrollen für Herausgeberidentität, Verteilungsintegrität, Prüfung installierter Dateien und Antivirus-Qualifikation. Keine davon garantiert, dass eine verhaltensbasierte Antivirus-Engine jede Operation akzeptiert.

Prüfung von Veröffentlichung und Aktualisierung

Windows-CLI-Release-Builds signieren zuvor unsignierte PE-Dateien mit dem Azure-Key-Vault-Zertifikat des Projekts, verlangen gültige Signaturen und Zeitstempel und prüfen das erwartete DEFAI-Zertifikat auf nativen Modulen aus erster Hand. Die gebündelte Node-Datei muss eine gültige Signatur der OpenJS/Node.js Foundation behalten. Ungültige vorhandene Signaturen lassen den Build fehlschlagen und werden nicht durch erneutes Signieren repariert.

Der Release-Herausgeber erzeugt runtime-integrity.json nach der nativen Signierung und deckt die endgültigen Bytes von JavaScript und nativer Nutzlast ab. Seine abgetrennte Minisign-Signatur ist im ZIP enthalten, bevor das endgültige Archiv signiert wird. Das ältere runtime-manifest.json bleibt ein nicht nativer Staging-Vertrag für den Desktop. Es ist nicht der Vertrauensanker der installierten Laufzeit.

Das Windows-Installationsprogramm prüft das Archiv vor dem Entpacken, authentifiziert dann das Integritätsmanifest und prüft die Nutzlast, bevor es den Kandidaten ausführt. Es prüft gestagte Kopien erneut und behält die Metadaten in der installierten Laufzeit. Ältere signierte Veröffentlichungen ohne diese Metadaten bleiben mit einer ausdrücklichen Legacy-Diagnose installierbar. Ein ungültiges Manifest oder eine ungültige Signatur wird nie als Legacy-Veröffentlichung behandelt. Die vorhandene ausdrückliche Abwahl der Signaturprüfung deaktiviert auch die Manifestauthentifizierung mit einer Warnung. Hashvergleiche laufen weiterhin und belegen in diesem Modus kein Vertrauen in den Herausgeber. Vorhandene Installationssperren, versionierte Generationen und die Rücknahme bleiben in Kraft.

Selbstaktualisierungen prüfen die Minisign-Signatur des versionierten Installationsskripts mit dem festgehaltenen öffentlichen Release-Schlüssel, bevor sie es ausführen, unter Windows und Unix. SHA-256-Sidecars bleiben eine zusätzliche Prüfung auf Beschädigung. Fehlende Signaturen scheitern geschlossen und fallen nicht auf unsignierte Ausführung zurück.

Diese Prüfungen schützen die Zulassung von Installation und Aktualisierung, erzwingen aber keine Signaturprüfung bei jedem Laden eines Node-Moduls und hindern einen lokalen Angreifer mit Schreibzugriff nicht daran, Starter oder Prüfer zu ersetzen. Ein getrennt signierter nativer Starter wäre eine zusätzliche Kontrolle, keine Voraussetzung für die Prüfung heruntergeladener Aktualisierungen.

Antivirus-Qualifikation

Der Ablauf Windows Installer Qualification prüft Installation und Rücknahme für x64 und ARM64. Seine manuelle Eingabe defender_scan verlangt zusätzlich aktivierten Defender-Schutz, scannt die installierte Laufzeit ohne scanausgelöste Bereinigung und zeichnet Versionen von Engine und Datenbank, Dateihashes und Scannerausgabe auf. Ein nicht verfügbarer Scanner lässt diese angeforderte Prüfung fehlschlagen. Das ist ein Defender-Scan-Schnappschuss, kein Nachweis der Kaspersky-Kompatibilität.

Verwenden Sie für die verhaltensbasierte Qualifikation von Kaspersky eine isolierte Windows-VM mit aktuellem Schutz und ohne Ausnahmen. Zeichnen Sie das genaue AX-Code-Artefakt, die Version und den Hash, den Windows-Build, Produkt, Engine und Datenbankversionen von Kaspersky sowie die Einstellungen auf. Üben Sie Neuinstallation, TUI-Start, Enter und Shift+Enter, eine normale Shell- oder PTY-Operation, eine Aktualisierung bei noch offener anderer Sitzung, Rücknahme und Deinstallation. Erfassen Sie das Erkennungsereignis und die Prozessherkunft. Prüfen Sie dasselbe Szenario nach einer Änderung erneut. Eine geänderte Paketierung ohne Reproduzierer belegt keine Korrektur.

Die Anleitung zu Falscherkennungen von Kaspersky verlangt einen GSI-Bericht für Windows-PDM-Erkennungen. Entwickler können das Kaspersky-Allowlist-Programm für eine vorausschauende Softwareprüfung bewerten. Beschränken Sie Einreichungen auf die relevanten öffentlichen Releasedateien und geprüfte Diagnosenachweise. Eine Anfrage einzureichen ist kein sauberes Urteil, und ein sauberer statischer Scan ist keine verhaltensbasierte Annahme.

Deaktivieren Sie den Schutz nicht, fügen Sie keine breiten Ausnahmen für das Installationsverzeichnis hinzu und stellen Sie unter Quarantäne gestellte Dateien nicht automatisch als Produktumgehung wieder her.