Questo documento riassume i rischi, le responsabilità e i limiti di LUX (MVP) con particolare attenzione alle operazioni distruttive di Panic, Wipe ed Encrypt.

• Le funzioni Panic/Wipe/Encrypt sono POTENZIALMENTE DISTRUTTIVE e possono causare perdita permanente di dati.
• Esegui in un ambiente pulito (idealmente initramfs), con i dischi di destinazione non montati e sistema alimentato in modo stabile.
• Verifica sempre due volte il device di destinazione (es.: /dev/sda vs /dev/sdb). Un errore di selezione è irreversibile.
• DEMO MODE non è una misura di sicurezza: serve solo a prevenire esecuzioni accidentali in fase di test. Per passare al comportamento reale occorre azione esplicita.

• L’utente è l’unico responsabile dell’uso degli strumenti e del rispetto di norme/capitolati interni, requisiti legali e standard di settore.
• In caso di necessità di bonifica “certificabile”, verifica i requisiti formali del tuo ente (report, checksum, evidenze fotografiche/log, identificativi univoci dei dispositivi, catena di custodia).
• LUX (MVP) non fornisce garanzie; l’idoneità va valutata e documentata caso per caso.

• Obiettivo: minimizzare il tempo fino a rendere i dati inaccessibili.
• Azioni tipiche (vedi script):
  • “Header‑kill”: azzera i primi/ultimi 10 MiB (distruzione MBR/GPT e metadati noti).
  • SSD: ATA Security Erase (SATA) o NVMe crypto erase (nvme format -s1), che invalida le chiavi interne.
• Pro: molto rapido, efficace su supporti cifrati/SSD quando l’implementazione è corretta.
• Contro: non sovrascrive l’intera superficie; non sempre accettato come “wipe certificabile”.

• Obiettivo: bonifica completa con evidenze verificabili.
• Azioni tipiche (vedi script):
  • Secure Erase se disponibile e ammesso dalla policy.
  • In alternativa: 1‑pass zero‑fill (veloce) oppure profilo DoD 3 pass (zero, 0xFF, random).
  • Verifica: lettura finale di blocchi (es.: ultimo MiB) e report esito.
• Pro: più aderente a requisiti di audit (dipende dalle policy).
• Contro: lento (molto su dischi capienti); su SSD i multi‑pass non sono sempre raccomandati per via del wear‑leveling e aree rimappate.

• BitLocker/TPM: modifiche alla ESP o al layout di boot possono richiedere la sospensione dei protector (es.: manage-bde -protectors -disable C:) per evitare schermate di recovery.
• Panic su supporti cifrati: la distruzione di metadati/chiavi può risultare sufficiente a inibire l’accesso ai dati, ma verifica le tue policy prima di adottarla come unica misura.
• Secure Boot: l’MVP non è firmato. Per il PoC va disattivato; in roadmap è prevista una catena firmata (shim/MOK, GRUB e kernel firmati).

• SATA: hdparm --security-erase(-enhanced) richiede spesso il disco in stato “not frozen”; può servire sospensione/resume o power‑cycle. Non tutti i firmware implementano correttamente le specifiche.
• NVMe: nvme format -s1 effettua crypto erase quando supportato. Alcuni controller offrono anche comandi “sanitize” (più lenti ma più approfonditi). Consultare la documentazione del produttore.
• SAS/enterprise: potrebbero esistere comandi specifici (Sanitize, Instant Secure Erase). Verificare tool e supporto.

• SSD: wear‑leveling, over‑provisioning e settori rimappati possono rendere i multi‑pass non deterministici; le operazioni basate su chiavi (crypto erase) dipendono dalla corretta implementazione del vendor.
• HDD: i multi‑pass possono aumentare confidenza ma allungano drasticamente i tempi senza garanzia “assoluta”. Le linee guida moderne spesso raccomandano 1 pass + verifica o metodi di sanitizzazione specifici.
• Cache, journaling, metadati di FS e firmware possono persistere finché non gestiti esplicitamente.
• Per certificazioni formali: raccogli log, identificativi del device (seriale/modello), esiti dei comandi e campionamenti di verifica. Conserva i report secondo la policy.

• Default: DEMO mode attivo negli script e nell’UI (operazioni pericolose bloccate o simulate).
• Sblocco (DISTRUTTIVO):
  • Script: esporta DEMO_MODE=0 (es.: DEMO_MODE=0 /engine/wipe.sh -d /dev/sdX).
  • UI: ricompila lux-ui con -DDEMO_MODE=0 e assicurati di sapere esattamente quali script verranno eseguiti.
• Ricorda: DEMO mode non è un meccanismo di sicurezza o di “cancellazione logica”; è solo un guard‑rail per test.

• Esegui da initramfs o ambiente live dedicato; non operare sul disco da cui stai eseguendo.
• Scollega unità non target quando possibile per ridurre il rischio di errore.
• Alimentazione stabile; evita portatili a batteria scarica o ambienti a rischio interruzione.
• Conserva copie dei log e, dove richiesto, delle evidenze di verifica.

Se riscontri vulnerabilità o comportamenti inattesi, apri un’issue descrivendo ambiente, modello dei dischi e comandi usati; non allegare dati sensibili.