Indicazioni sulla sicurezza

L'interfaccia della riga di comando di winapp semplifica lo sviluppo di Windows locale: può generare un certificato di firma, considerarlo attendibile nel computer e attivare automaticamente la modalità sviluppatore. Ognuno di questi passaggi modifica lo stato della macchina o crea un file che contiene una chiave privata, in modo da poter sapere esattamente cosa fanno.

Questa pagina illustra la conseguenza di ogni comando, come annullarlo e cosa fare in modo diverso quando si spedisce. I certificati di sviluppo e la Modalità sviluppatore sono la via standard e supportata per i test locali — l’obiettivo è che tu capisca a cosa stai scegliendo di aderire, non che tu li eviti.

Certificati di sviluppo

I pacchetti MSIX devono essere firmati prima che Windows li installi. Per i test locali, winapp cert generate crea un certificato autofirmato in modo da poter firmare e installare il proprio pacchetto senza acquistare nulla.

Che cosa crea winapp cert generate

Il certificato generato è un certificato autofirmato di firma del codice dell'entità finale:

Proprietà Valore
Key RSA a 2048 bit, contrassegnata come esportabile
Algoritmo di firma SHA-256 con RSA (PKCS#1 v1.5)
Utilizzo delle chiavi Firma digitale
Utilizzo chiavi avanzato Firma del codice (1.3.6.1.5.5.7.3.3)
Vincoli di base Non un'autorità di certificazione
Validità 365 giorni per impostazione predefinita (--valid-days)
Oggetto Deve corrispondere a Publisher nel manifesto

Il comando scrive due cose:

  • devcert.pfx nella directory corrente (o nel percorso specificato con --output). Questo file contiene sia il certificato che la relativa chiave privata.
  • Copia del certificato nell'archivio certificati personale (Cert:\CurrentUser\My).

Con --export-cer, scrive anche un .cer file accanto a .pfx. Tale file contiene solo il certificato pubblico, nessuna chiave privata, che lo rende la cosa giusta da consegnare a un compagno di squadra o a un computer di test che deve considerare attendibili le compilazioni.

Annotazioni

Un certificato autofirmato è considerato attendibile da nessuno finché qualcuno non lo considera attendibile in modo esplicito. Va bene per il proprio computer e i propri computer di test; non è un sostituto di un'identità di firma del codice reale quando si distribuisce l'app.

Password predefinita

winapp cert generate usa password come password del PFX, a meno che non venga passato --password. Lo stesso valore predefinito si applica quando si specifica successivamente il certificato a winapp sign, la cui opzione password è anche --password, e a winapp pack, che accetta --cert-password.

Una password nota indica che la chiave privata in devcert.pfx è effettivamente non protetta. Chiunque ottenga il file possa firmare il codice con esso. Questo è un compromesso accettabile per un certificato usa e getta che viene usato solo per firmare build di test locali sul proprio computer, ed è per questo che esiste l'opzione predefinita.

Importante

Considerare la password predefinita come segnale che il certificato è eliminabile. Se un certificato viene mai usato per firmare un elemento che verrà installato da un'altra persona, non deve essere un winapp cert generate certificato con la password predefinita. Vedere Firma per l'ambiente di produzione.

Gli script e gli agenti non devono confrontare la password stessa: winapp cert generate --json segnala "defaultPasswordIsPublic": true e ripete la divulgazione in una warnings matrice ogni volta che il valore predefinito è attivo. Vedere Generare l'output JSON del certificato.

Posizione in cui risiede il file del certificato

devcert.pfx è una chiave privata su disco. Due regole lo tengono fuori dai problemi:

Non eseguirne il commit.winapp cert generate aggiunge automaticamente il nome del file del certificato all'oggetto .gitignore accanto, quindi il flusso predefinito è già coperto. Se si sposta il file, lo si rinomina o lo si genera in una directory gestita da un'altra .gitignore, verificare che la voce lo abbia seguito:

git check-ignore -v devcert.pfx

Se non stampa nulla, il file non viene ignorato: aggiungilo prima di eseguire il commit.

Non includerlo nel pacchetto.winapp pack crea un pacchetto con tutto il contenuto della directory di input, quindi un devcert.pfx che si trova nella cartella di output dell'app finisce all'interno dell'MSIX distribuito. Generare il certificato all'esterno della cartella inserita nel pacchetto, come illustrato nella guida alla creazione di pacchetti di un'interfaccia della riga di comando e verificare che sia assente prima della distribuzione:

# Unpack the package and check that no certificate is inside
winapp tool makeappx unpack /p .\MyApp.msix /d .\inspect /o
Get-ChildItem .\inspect -Recurse -Include *.pfx, *.cer

Tip

Se un .pfx con una chiave privata reale viene effettivamente sottoposto a commit o pubblicato, sostituitelo: generate un nuovo certificato, firmatelo di nuovo e smettete di considerare attendibile quello precedente seguendo la procedura descritta in Rimozione di un certificato attendibile. L'eliminazione del file da un commit successivo non la rimuove dalla cronologia.

Cosa concede winapp cert install

winapp cert install aggiunge il certificato all'archivio LocalMachine\TrustedPeople . Questo richiede privilegi di amministratore, perché modifica l'attendibilità per ogni utente nel computer.

Una volta che un certificato è in TrustedPeople, Windows accetterà qualsiasi pacchetto MSIX firmato da tale certificato come attendibile da installare, non solo il pacchetto che si stava testando. Per un certificato di cui si possiede la chiave privata e la si conserva localmente, è proprio questo l'effetto previsto. È anche il motivo per cui bisogna essere ponderati al riguardo:

  • Considera attendibili i certificati che hai generato tu stesso o che provengono da qualcuno a cui permetteresti di installare software sul computer.
  • Non installare un certificato di sviluppo su computer condivisi, di produzione o di build su cui fanno affidamento altre persone.
  • È preferibile distribuire il .cer (solo chiave pubblica) anziché il .pfx quando un collega deve installare il pacchetto di test. Acquisiscono la capacità di fidarsi delle tue build senza acquisire la capacità di firmare al posto tuo.

Per considerare attendibile un .cer su un'altra macchina di test, esegui direttamente winapp cert install su di essa: il comando accetta sia un .pfx sia un .cer contenente solo la chiave pubblica:

# Run as Administrator
winapp cert install .\devcert.cer

L'equivalente che usa solo gli strumenti Windows predefiniti è:

# Run as Administrator
Import-Certificate -FilePath .\devcert.cer -CertStoreLocation Cert:\LocalMachine\TrustedPeople

Rimozione di un certificato attendibile

I certificati di sviluppo scadono dopo un anno per impostazione predefinita, ma la scadenza non viene rimossa. Quando non hai più bisogno di un certificato — perché il progetto è terminato, la macchina viene riutilizzata o la chiave potrebbe essere stata compromessa — rimuovilo esplicitamente.

Per prima cosa, trova la sua impronta digitale:

Get-ChildItem Cert:\LocalMachine\TrustedPeople |
    Where-Object { $_.Subject -like '*CN=Contoso*' } |
    Format-List Subject, Thumbprint, NotAfter

Quindi rimuovilo dall'archivio certificati attendibili del computer. Questo passaggio richiede l'elevazione dei privilegi:

# Run as Administrator. Replace with the thumbprint from the previous command.
$thumbprint = 'ABCD...'
Remove-Item -Path "Cert:\LocalMachine\TrustedPeople\$thumbprint"

cert generate inoltre ha inserito il certificato, insieme alla relativa chiave privata, nell'archivio personale. Rimuovi tale elemento da un prompt normale, non elevato, con accesso effettuato con l’account che ha eseguito cert generate:

$thumbprint = 'ABCD...'
Remove-Item -Path "Cert:\CurrentUser\My\$thumbprint"

Importante

Eseguire i due comandi precedenti nei contesti visualizzati. Se l'elevazione è stata eseguita usando un account amministratore diverso, Cert:\CurrentUser in tale sessione con privilegi elevati si riferisce all'archivio di quell'amministratore, non al tuo, quindi la chiave privata rimarrebbe nell'archivio dell'utente che l'ha generata.

Infine, elimina .cer e tutte le copie .pfx che hai distribuito, quindi deregistra i pacchetti che hai installato manualmente con esso:

winapp unregister

Annotazioni

La rimozione del certificato non disinstalla i pacchetti già installati. Disinstalla separatamente tali elementi tramite Impostazioni > App > App installate, oppure con winapp unregister per i pacchetti registrati in modalità di sviluppo.

Modalità di sviluppo

Windows richiede la modalità sviluppatore per registrare un pacchetto dell'app direttamente da una cartella su disco, ovvero un layout libero, invece di installare un MSIX compilato e firmato. Comandi come winapp run e create-debug-identity si basano su questo e non riescono senza di esso e winapp init offre di attivarlo per l'utente.

Cosa cambia quando lo si abilita

La CLI abilita la Modalità sviluppatore scrivendo due valori DWORD in HKEY_LOCAL_MACHINE:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock
    AllowDevelopmentWithoutDevLicense = 1
    AllowAllTrustedApps               = 1

Poiché si tratta di impostazioni a livello di computer, l'interfaccia della riga di comando avvia un processo helper con privilegi elevati e Windows mostra una richiesta di controllo dell'account utente. Se si rifiuta la richiesta, non viene modificato nulla.

In pratica, ciò significa che la macchina:

  • Registrare i pacchetti dell'app direttamente da una cartella su disco, senza che siano incorporati in msiX o firmati (AllowDevelopmentWithoutDevLicense).
  • Installare i pacchetti dell'app al di fuori di Microsoft Store purché siano firmati da un certificato considerato attendibile dal computer, compreso qualsiasi certificato di sviluppo in TrustedPeople (AllowAllTrustedApps).

Importante

La modalità sviluppatore più un certificato di sviluppo attendibile è un'eliminazione intenzionale delle restrizioni di installazione predefinite. Quella combinazione va usata su macchine di sviluppo e test. Lasciarlo disattivato nei computer di produzione, nei chioschi multimediali e nell'infrastruttura condivisa.

Controllo quando è abilitato

winapp init chiede prima di modificare qualsiasi cosa e --use-defaults ignora completamente la domanda, lasciando invariata la modalità sviluppatore. Questo rende sicure per impostazione predefinita le esecuzioni da script e quelle di CI:

winapp init --use-defaults

Se preferisci gestire l'impostazione manualmente, abilitala una volta sola tramite Impostazioni > Sistema > Per sviluppatori > Modalità sviluppatore e la CLI la rileverà e proseguirà.

Disattivazione

Usa sistema > di impostazioni > per gli sviluppatori e disattiva la modalità sviluppatore. Questo è il percorso consigliato, perché Impostazioni pulisce anche lo stato del sistema operativo associato. Per confermare successivamente il valore del Registro di sistema:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock' `
    -Name AllowDevelopmentWithoutDevLicense, AllowAllTrustedApps

La disattivazione della modalità sviluppatore non rimuove i certificati attendibili o i pacchetti già installati. Vedere Rimozione di un certificato attendibile.

Firma per la produzione

Un certificato di sviluppo funziona solo per le persone che lo hanno considerato attendibile in modo esplicito. Per distribuire l'app, firmala con un'identità che Windows considera già attendibile.

Scegliere un'identità di firma

  • Firma attendibile di Azure: un servizio di firma gestito dal cloud. La chiave privata non è mai presente sulla macchina di build, quindi non c’è alcuna .pfx da proteggere, divulgare o ruotare manualmente. Usare winapp az-sign, che esegue l'autenticazione con la catena di credenziali standard Azure e funziona con GitHub Actions OIDC o un'identità gestita.

    winapp az-sign .\MyApp.msix

  • Un certificato di firma del codice da un'autorità di certificazione attendibile , passarlo a winapp sign come secondo argomento posizionale, con la relativa password in --password. Sei quindi responsabile di conservare il materiale crittografico in modo sicuro; conservalo in un token hardware, in un vault delle chiavi o nell'archivio dei segreti del tuo provider CI, e mai nel repository.

  • Il Microsoft Store : se si distribuisce esclusivamente tramite lo Store, firma il pacchetto per te e non devi firmare prima dell'invio.

In ogni caso, il soggetto del certificato deve corrispondere al valore Publisher nel manifest, anche per i pacchetti sparse.

Tieni i segreti di firma fuori dal repository

Le password dei certificati appartengono all'archivio dei segreti CI, non in un file di configurazione. Leggili dall'ambiente invece di codificarli direttamente nel codice:

winapp sign .\MyApp.msix $env:SIGNING_CERT_PATH --password $env:SIGNING_CERT_PASSWORD

Lo stesso vale per la configurazione di build archiviata nel controllo del codice sorgente, ad esempio una configurazione di Electron Forge — vedi Packaging di Electron. winapp az-sign evita completamente il problema, perché non esiste alcuna password da passare.

Prima di pubblicare

Breve elenco di controllo per la transizione dal test locale alla distribuzione:

  • Il pacchetto viene firmato con un certificato rilasciato dalla CA, Firma attendibile di Azure o inviato allo Store, non con devcert.pfx.
  • Nell'output del pacchetto non è presente alcun file .pfx o .cer.
  • Nessuna password del certificato viene visualizzata nei file di cui è stato eseguito il commit, negli script di compilazione o nei log ci.
  • L'oggetto del certificato corrisponde al manifesto Publisher.
  • I certificati di sviluppo e la modalità sviluppatore non sono abilitati nei computer che devono solo eseguire l'app.

Segnalazione di un problema di sicurezza

Per segnalare una vulnerabilità di sicurezza nell'interfaccia della riga di comando winapp stessa, seguire il processo in SECURITY.md. Non aprire una segnalazione pubblica su GitHub per le segnalazioni di sicurezza.

  • Last updated on