Sicurezza e privacy
TSR lavora sul tuo computer: i file che comprimi non vanno da nessuna parte. Qui c’è come protegge gli archivi, come si aggiorna, che cosa manda se glielo permetti, e come segnalare una vulnerabilità.
Con una password l’archivio è cifrato per intero con XChaCha20-Poly1305, indice compreso: nomi, dimensioni, date e permessi dei file restano segreti. La chiave nasce dalla password con Argon2id, coi parametri scritti nell’archivio, così domani si possono alzare senza rompere gli archivi di ieri.
Ogni blocco e ogni file portano l’impronta BLAKE3 del contenuto originale. Una password sbagliata e un archivio manomesso danno due errori diversi, e la verifica dice quale file è danneggiato e dove.
Con la parità Reed–Solomon, dall’1 al 30 %, un danno entro la quota si ripara in un file nuovo. La parità copre i byte fisici: chi custodisce il supporto può ripararlo senza il diritto di leggerlo.
Zero crittografia scritta in proprio: primitive pubbliche e collaudate (XChaCha20-Poly1305, Argon2id, BLAKE3, Reed–Solomon), usate come previsto. Di un archivio cifrato restano visibili la dimensione totale e quante volte è stato esteso.
TSR è scritto in Rust, che elimina per costruzione le classi di difetti più sfruttate nei programmi che leggono file. Ogni campo di dimensione letto da un archivio ha un tetto: un archivio ostile di 299 byte con la dimensione gonfiata è respinto in un decimo di secondo. In estrazione i percorsi non escono mai dalla cartella scelta, e i collegamenti non si seguono.
Il fuzzing a copertura gira su 18 bersagli, uno per ogni lettore di ingresso, sotto il rilevatore di errori di memoria: 11,77 milioni di esecuzioni registrate, zero difetti. Prima che una modifica entri nel repository, un controllo locale lo ripete per dieci secondi a bersaglio.
La beta legge periodicamente un documento firmato dal nostro server, mandando solo la sua versione e il sistema operativo. Ogni aggiornamento è firmato con una chiave che sta cifrata sul computer dell’autore, mai sul server: il programma verifica firma, dimensione e impronta prima di installarlo, lo installa al riavvio, mai durante un lavoro, e tiene la versione precedente per tornare indietro.
Un server che mentisse, con un pacchetto diverso o un documento senza la firma giusta, non riuscirebbe a installare niente: lo prova, a ogni versione, una serie di test sui pacchetti veri.
Al primo avvio la beta chiede se vuoi mandarci i rapporti dei crash e le metriche d’uso: sono due scelte separate, e restano spente finché non le accendi. Un rapporto di crash dice dove si è fermato il programma; una metrica d’uso dice quale operazione, con che esito e con numeri arrotondati.
Non partono mai nomi di file o cartelle, percorsi, contenuti, nomi utente o password. Gli eventi sono legati a un identificativo casuale creato sul tuo computer, restano novanta giorni su un nostro server nell’Unione europea, che non conserva gli indirizzi IP, e li cancelli da solo dalle preferenze.
tsr beta sonda mostra stampa gli eventi in coda esattamente come partiranno; tsr beta sonda cancella chiede al servizio di cancellare quelli arrivati; TSR_SONDA=0 spegne tutto.
Ogni pacchetto ha la sua impronta SHA-256, pubblicata nella pagina di download e nel file SHA256SUMS, che porta una marca temporale qualificata eIDAS. I programmi non sono ancora firmati con i certificati di Apple e di Microsoft: su macOS la firma è ad hoc, e fino ai certificati i sistemi avvisano al primo avvio.
Scrivi a matteo@feroldi.cloud con oggetto [TSR sicurezza], senza aprire segnalazioni pubbliche e senza pubblicare i dettagli prima della data concordata. Se vuoi cifrare la segnalazione, dillo nel primo messaggio: la chiave si scambia in risposta.
Una segnalazione utile dice la versione (tsr --version), il sistema, i passi per riprodurre e, se c’è, il file che scatena il problema. Per ogni vulnerabilità confermata in una versione distribuita si chiede un identificatore CVE, e l’avviso esce con la versione corretta.
La politica completa è nel file SECURITY.md dentro ogni pacchetto; i contatti anche in security.txt.
| Passo | Entro |
|---|---|
| Ricevuta, con un riferimento | 3 giorni lavorativi |
| Valutazione: confermata o no, gravità (CVSS 3.1), versioni colpite | 10 giorni lavorativi |
| Correzione in una versione nuova | gravità alta o critica: 30 giorni; media o bassa: entro 90 |
| Avviso pubblicato | con la versione corretta, e comunque entro 90 giorni dalla segnalazione |
