Hanno rotto Signal
Sì, ma non come si potrebbe pensare.
Signal è vivo e lotta insieme a noi. E dopo le recenti genuflessioni di Telegram in merito alla privacy (che per la verità Telegram, strutturalmente, non ha mai garantito) è rimasto l'unico vero competitor, fra Whatsapp e Telegram appunto, che può garantire un invidiabile livello di sicurezza.
L'unico neo, come è noto, era dato dalla versione desktop che non cifrava i dati a riposo e che signal.org aveva sempre delegato ad una cifratura di tipo Full Disk Encryption, lasciando però quello che sembrava a tutti gli effetti una bella voragine di sicurezza per un'applicazione che fa proprio della sicurezza il suo mantra
Purtroppo il passaggio alla 7.24.1 e conseguente rilascio della cifratura del db per i dati a riposo che colmava il gap, se da un lato faceva levare osanna e grida di giubilo, dall'altro innescava, in alcuni casi e solo su Gnu/Linux pare, il censimento dei santi del calendario per via della rottura del db di Signal.
Su Gnu/Linux l'unica versione disponibile è quella via flatpak, il repository per le distro debian-based al momento è indisponibile. L'aggiornamento va a modificare la chiave di cifratura contenuta nel file .var/app/org.signal.Signal/config/Signal/config.json, passando da una chiave in chiaro ad una cifrata, che però Signal non riesce più ad utilizzare.
Quando si avvierà Signal dopo l'aggiornamento, l'impossibilità di accedere al database, farà comparire questo errore (o simile)
che implica la perdita di ogni dato archiviato.
In altri casi l'alert può far riferimento all'indisponibilità di gnome-libsecret per la decifratura della chiave. E nel mio caso, Fedora 40 con Gnome 46, la cosa è abbastanza seccante. Sarà Flatpak che non si integra bene con Gnome? Non lo so, fatto sta che mi sono trovato con SignalDesktop KO
L'errore è stato già segnalato su https://github.com/signalapp/Signal-Desktop/issues/7029 con relativo workaround che prevede per ora il rollback alla versione col db vulnerabile.
1. È necessario disporre innanzitutto di un backup di signal pre-aggiornamento (non banale, me ne rendo conto) che abbia ancora la chiave in chiaro.
2. Successivamente bisogna fare un rollback alla versione precedente (7.23 o 7.22 per es.)
# Elenca tutti i commit disponibili su flatpak. Selezionare l'id delle versione di interesse.
flatpak remote-info --log flathub org.signal.Signal
# Esegue il rollback alla versione indicata
flatpak update --commit <indice del commit scelto> org.signal.Signal
3. Controllare che il file $HOME/.var/app/org.signal.Signal/config/Signal/config.json non sia in questo stato:
...
"encryptedKey": "la mia chiave cifrata",
"safeStorageBackend": "gnome_libsecret"
...
ma in questo:
...
"Key"="la mia chiave in chiaro"
...
4. In base alla versione del backup potrebbe essere necessario un rollback ancora più estremo. Un'indicazione viene data dall'esecuzione via cli che, nel caso flatpak corrisponde a lanciare:
/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=signal-desktop --file-forwarding org.signal.Signal
Se dovesse comparire un errore di questo tipo (a me è successo)
Database startup error: DBVersionFromFutureError: SQL: User version is 1190 but the expected maximum version is 1150
allora occorre individuare qui il commit relativo alla versione di signal compatibile con la versione indicata dall'errore e ripetere i primi 2 punti.
Purtroppo, facendomi prendere dalla foga, ho pasticciato con le configurazioni prima di backupparle e non sono riuscito a fare più nulla, avevo perso la chiave in chiaro.
Ma magari, per altri, qualche speranza c'è.
EDIT: 04/10/2024
Ho riprodotto l’errore e il relativo rollback. Ecco come ho fatto.
Premessa importante
L’avvio di Signal-Desktop dopo l’aggiornamento alla 7.24.1 non spacca tutto come avevo erroneamente fatto intendere ma fa comparire un warning sulla possibilità di cifrare la chiave di cifratura del db (un’altra mia imprecisione. Il db non è mai stato in chiaro, è sempre stato cifrato ma la chiave è lasciata in bella mostra in chiaro. Quindi utile come una porta chiusa a 10 mandate con la chiave lasciata nella toppa), a tuo rischio e pericolo, facendo l’override di una variabile d’ambiente, SIGNAL_PASSWORD_STORE, impostata inizialmente a “basic” (in chiaro) e da impostare come “gnome_libsecret” per attivare la cifratura.
/usr/bin/flatpak --user override --env=SIGNAL_PASSWORD_STORE=gnome-libsecret org.signal.Signal
Che è quello che ho fatto anche io.
E la chiave in chiaro:
{
"key": "la mia chiave in chiaro"
}
diventa:
{
"encryptedKey": "la mia chiave supercifrata",
"safeStorageBackend": "gnome_libsecret"
}
Purtroppo una volta fatto così, Signal cessa di funzionare perché la chiave non è più utilizzabile
Qual è il banale workaround?
Se volete provare il brivido dell’imprevisto, senza recuperare vecchi commit, anche dopo l’aggiornamento ma prima di fare l’override, bisogna fare un backup della cartella dati con un semplice tar:
tar -cf $HOME/signal_backup.tar $HOME/.var/app/org.signal.Signal
Facendo l’override e riavviando signal ecco che ricompare:
Per non correre rischi (magari è pure inutile) ho riscritto la variabile d'ambiente eliminando la cifratura:
/usr/bin/flatpak --user override --env=SIGNAL_PASSWORD_STORE=basic org.signal.Signal
Le scelte a questo punto sono due (verificate entrambe):
- Ripristinare il backup dal tar che deve rimpiazzare completamente
$HOME/.var/app/org.signal.Signal - Sostituire il solo file config.json in
~/.var/app/org.signal.Signal/config/Signal