Questa pagina è tradotta dalla documentazione inglese. Comandi, identificatori ed esempi restano invariati. Runtime 7.24.4 · SDK 2.6.7. Testo inglese

Integrità del runtime Windows e segnalazioni antivirus

Stato: sorgente attuale; qualifica di rilascio in sospeso Ambito: installazione della CLI su Windows, verifica degli aggiornamenti e diagnostica per operatori Ultima revisione: 2026-09-17 Responsabile: manutentori del runtime di AX Code

AX Code usa controlli separati per l’identità dell’editore, l’integrità della distribuzione, la verifica dei file installati e la qualifica antivirus. Nessuno di questi è una garanzia che un motore antivirus comportamentale accetti ogni operazione.

Verifica di rilascio e di aggiornamento

Le build di rilascio della CLI per Windows firmano i file PE prima non firmati usando il certificato Azure Key Vault del progetto, richiedono firme e timestamp validi e controllano il certificato DEFAI atteso sui moduli nativi di prima parte. L’eseguibile Node incluso deve conservare una firma valida della OpenJS/Node.js Foundation. Le firme esistenti non valide fanno fallire la build; non vengono riparate con una nuova firma.

L’editore del rilascio crea runtime-integrity.json dopo la firma nativa, coprendo i byte finali del payload JavaScript e nativo. La firma Minisign staccata è inclusa nello ZIP prima che l’archivio finale venga firmato. Il più vecchio runtime-manifest.json resta un contratto di staging non nativo per Desktop; non è l’ancora di fiducia del runtime installato.

L’installer per Windows verifica l’archivio prima dell’estrazione, poi autentica il manifesto di integrità e verifica il payload prima di eseguire il candidato. Controlla di nuovo le copie in staging e conserva i metadati nel runtime installato. I rilasci firmati più vecchi privi di questi metadati restano installabili con una diagnostica legacy esplicita. Un manifesto o una firma non validi non vengono mai trattati come un rilascio legacy. La disattivazione esplicita già esistente della verifica della firma disabilita anche l’autenticazione del manifesto, con un avviso; i confronti degli hash vengono comunque eseguiti e non stabiliscono la fiducia nell’editore in quella modalità. I lock di installazione esistenti, le generazioni versionate e il rollback restano in vigore.

Gli auto-aggiornamenti verificano la firma Minisign dello script di installazione versionato usando la chiave pubblica di rilascio fissata, prima di eseguirlo, su Windows e su Unix. I sidecar SHA-256 restano un controllo aggiuntivo contro la corruzione. Le firme assenti fanno fallire in modo chiuso; non si ripiega sull’esecuzione non firmata.

Questi controlli proteggono l’ammissione di installazione e di aggiornamento. Non impongono la validazione della firma a ogni caricamento di modulo Node e non impediscono a un attaccante locale con accesso in scrittura di sostituire il launcher o il verificatore. Un launcher nativo firmato a parte sarebbe un controllo aggiuntivo, non un prerequisito per verificare gli aggiornamenti scaricati.

Qualifica antivirus

Il workflow Windows Installer Qualification prova l’installazione e il rollback su x64 e ARM64. Il suo input manuale defender_scan richiede in più la protezione Defender abilitata, analizza il runtime installato senza rimedio innescato dalla scansione e registra le versioni di motore e database, gli hash dei file e l’output dello scanner. Uno scanner non disponibile fa fallire questo controllo richiesto. È un’istantanea di scansione Defender, non un’evidenza di compatibilità con Kaspersky.

Per la qualifica comportamentale di Kaspersky, usa una VM Windows isolata con protezione aggiornata e senza esclusioni. Registra l’artefatto e la versione esatti di AX Code e l’hash, la build di Windows, le versioni di prodotto, motore e database di Kaspersky e le impostazioni. Esercita installazione da zero, avvio della TUI, Enter e Shift+Enter, un’operazione normale di shell/PTY, aggiornamento mentre un’altra sessione resta aperta, rollback e disinstallazione. Cattura l’evento di rilevamento e l’ascendenza dei processi. Riesegui lo stesso scenario dopo una modifica; cambiare il packaging senza un riproduttore non stabilisce una correzione.

La guida sui falsi rilevamenti di Kaspersky chiede un rapporto GSI per i rilevamenti PDM su Windows. Gli sviluppatori possono valutare il programma Kaspersky Allowlist per una revisione proattiva del software. Limita gli invii ai file pubblici di rilascio pertinenti e all’evidenza diagnostica già revisionata. Presentare una richiesta non è un verdetto pulito, e una scansione statica pulita non è un’accettazione comportamentale.

Non disabilitare la protezione, non aggiungere ampie esclusioni della directory di installazione e non ripristinare in automatico i file in quarantena come soluzione del prodotto.