Benvenuti nella pagina Wiki di Simone Giustetti.
Lingue: English - Italiano
Migrazione delle password da Seamonkey 1.1.x a 2.0.x
Una delle funzioni che ritengo più utili di Seamonkey, il web browser integrato con un client e-mail, un editor Html ed un programma di Chat della fondazione Mozilla, è la possibilità di memorizzare le password con cui si accede ai siti consentendone l'uso mediante la digitazione di una singola "Master Password". Chiunque come me abbia la necessità di accedere a numerosi siti che richiedano di autenticarsi per operare comprenderà la comodità di amministrare una singola password piuttosto che alcune decine. Recentemente ho eseguito un upgrade di Seamonkey dalla versione 1.1.8 alla più nuova 2.0.4 contestualmente all'aggiornamento della versione di Slackware da 13.0 a 13.1. Al termine della procedura di aggiornamento mi sono purtroppo accorto di un problema relativo alle password salvate: le stesse non erano state importate dal vecchio profilo al nuovo. Ad ogni avvio Seamonkey lamentava un'incongruenza inerente la configurazione del sistema crittografico e disabilitava il modulo di autenticazione.
Riconfigurare decine di password non era un'opzione e mi sono pertanto adoperato per rieseguire l'importazione manualmente. Nel seguito dell'articolo esporrò la metodologia adoperata per importare manualmente le password dalla versione 1.1.8 alla 2.0.4 di Seamonkey.
Un problema noto
Non sono sicuramente il primo nè l'ultimo ad imbattersi nel problema. Una ricerca su Google ha evidenziato alcune segnalazioni su Bugzilla per le versioni alpha di Seamonkey 2.0: bugzilla.mozilla.org. Il problema sembrava chiuso, ma sui forum alcuni lamentavano gli stessi sintomi per le successive versioni stabili: forums.mozillazine.org
Ho seguito le procedure consigliate, rimosso la nuova versione, reinstallato la 1.1.8 e rieseguito l'aggiornamento, ma l'importazione delle password non sembrava funzionare comunque. Data la delicatezza dei dati ho quindi deciso di non ricorrere a strumenti automatici, ma di procedere manualmente.
Il primo passo è consistito nello studiare le metodologie con cui sono immagazzinate le informazioni per le versioni 1.x e la 2.x di Seamonkey. Le informazioni riportate nei link elencati di seguito hanno fatto un pò di luce circa le password in Seamonkey 1.x. Il resto lo ho dedotto procedendo mediante tentativi.
http://kb.mozillazine.org/Transferring_data_to_a_new_profile_-_SeaMonkey http://seamonkey.ilias.ca/profilefaq/#transferring_passwords http://snarfed.org/space/change_firefoxs_saved_passwords
Password in Seamonkey 1.1.x
Le informazioni inerenti le password sono salvate in un file avente estensione *.s nella versione 1.1.8 di Seamonkey. Nel caso in cui si facesse ricorso ad una Masterkey, cioè ad una password principale, la medesima e l'identificatore delle altre sono memorizzati nel file key3.db come il precedente contenuto nel profilo dell'utente.
Nel mio caso i file contenenti le informazioni erano:
/home/twinstar/.mozilla/default/xt5ed1fd.slt/key3.db /home/twinstar/.mozilla/default/xt5ed1fd.slt/52829682.s
Analizziamo un estratto del contenuto del file 52829682.s in modo da capire come siano organizzate le informazioni ivi contenute.
bash-4.1$ cd /home/twinstar/.mozilla/default/xt5ed1fd.slt bash-4.1$ cat 52829682.s #2c http://localhost http://www.giustetti.net https://localhost https://login.yahoo.com . http://appdb.winehq.org sUserEmail MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC... *sUserPassword MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC... . https://sourceforge.net form_loginname MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC... *form_pw MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC... .
Una riga singola contenente solo un punto rappresenta il terminatore di una voce o di una sezione.
Le 4 righe in testa al file comprese tra il simbolo #2c ed il primo punto consistono nell'elenco dei siti di cui non debba mai essere salvata la password.
La riga http://appdb.winehq.org introduce l'inizio di una password salvata relativa al sito appdb.winehq.org. Le righe che seguono contengono le informazioni relative alla maschera di autenticazione del sito. In dettaglio:
http://appdb.winehq.org - E' l'indirizzo del sito presso cui ci si voglia autenticare. sUserEmail - E' il campo della maschera che contiene il nome dell'utente. MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC... - E' il nome dell'utente criptato in modo che non possa essere letto da utenti non autorizzati. *sUserPassword - E' il campo della maschera corrispondente alla password. MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC. - E' la password criptata.
Il punto nella riga seguente segnala al programma che sono terminati i dati relativi all'autenticazione presso il sito appdb.winehq.org. La riga successiva segna l'inizio di una nuova password codificata in maniera analoga a quela appena esposta.
Password in Seamonkey 2.0.x
La codifica delle password e la ritenzione di informazioni quali cookie, history, downloads ed altro ancora sono cambiati completamente nella versione 2.0.x di Seamonkey rispetto alla 1.1.x. E' stato introdotto l'uso di sqlite per rendere omogenea la codifica delle informazioni. Sqlite è una libreria che implementa un motore di database SQL privo di un server dedicato. I vecchi file di testo sono stati perciò sostituiti dai nuovi cookies.sqlite, downloads.sqlite, formhistory.sqlite, permissions.sqlite, places.sqlite, signons.sqlite e urlbarhistory.sqlite. Il file signons.sqlite contiene le password e sostituisce il vecchio file avente estensione *.s. La gestione delle password avviene tramite la coppia di file signons.sqlite e key3.db nella nuova versione di Seamonkey.
Per studiare il formato di signons.sqlite è necessario un client SQL in grado di interpretare i file aventi estensione *.sqlite ed una certa dimestichezza con il linguaggio SQL. Per quanto riguarda il primo punto, Slackware 13.1 è equipaggiata con il pacchetto sqlite-3.6.23.1-<arch>-1 che contiene sia le librerie necessarie per creare file di database che un interprete in grado di manipolare i dati. Il programma client è sqlite3 attraverso cui studieremo il formato del file contenente le password.
bash-4.1$ sqlite3 signons.sqlite SQLite version 3.6.23.1 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> .schema CREATE TABLE moz_disabledHosts (id INTEGER PRIMARY KEY,hostname TEXT UNIQUE ON CONFLICT REPLACE); CREATE TABLE moz_logins (id INTEGER PRIMARY KEY, hostname TEXT NOT NULL, httpRealm TEXT, formSubmitURL TEXT, usernameField TEXT NOT NULL, passwordField TEXT NOT NULL,encryptedUsername TEXT NOT NULL, encryptedPassword TEXT NOT NULL,guid TEXT, encType INTEGER); CREATE INDEX moz_logins_encType_index ON moz_logins(encType); CREATE INDEX moz_logins_guid_index ON moz_logins(guid); CREATE INDEX moz_logins_hostname_formSubmitURL_index ON moz_logins(hostname, formSubmitURL); CREATE INDEX moz_logins_hostname_httpRealm_index ON moz_logins(hostname, httpRealm); CREATE INDEX moz_logins_hostname_index ON moz_logins(hostname);
Il comando .schema fa si che il client renda la struttura del database e l'elenco delle tabelle. Nel caso del database signons.sqlite le tabelle contenute sono 2: moz_disabledHosts e moz_logins; la seconda è quella di nostro interesse.
Analizziamo il contenuto della tabella moz_logins mediante il comando .dump che esporta un elenco di istruzioni SQL il cui scopo consiste nel creare un back-up completo dei dati e della struttura tabellare.
sqlite> .dump moz_logins PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE moz_logins (id INTEGER PRIMARY KEY, hostname TEXT NOT NULL, httpRealm TEXT, formSubmitURL TEXT, usernameField TEXT NOT NULL, passwordField TEXT NOT NULL, encryptedUsername TEXT NOT NULL, encryptedPassword TEXT NOT NULL, guid TEXT,encType INTEGER); INSERT INTO "moz_logins" VALUES(1,'http://www.gemave.it',NULL,'http://www.gemave.it','username','password', 'MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC...','MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC...', '{cae1a5bb-56f8-4366-91cc-20bc2f7af323}',1); INSERT INTO "moz_logins" VALUES(3,'https://sourceforge.net',NULL,'https://sourceforge.net','form_loginname', 'form_pw','MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC...','MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC...', '{2f7d87e6-64db-418a-8f26-1ee4b1fec787}',1); INSERT INTO "moz_logins" VALUES(12,'http://appdb.winehq.org',NULL,'http://appdb.winehq.org','sUserEmail', 'sUserPassword','MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC...','MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC...', '{3c600fba-7ec9-4deb-b644-f775defad46f}',1); CREATE INDEX moz_logins_hostname_index ON moz_logins(hostname); CREATE INDEX moz_logins_hostname_formSubmitURL_index ON moz_logins(hostname, formSubmitURL); CREATE INDEX moz_logins_hostname_httpRealm_index ON moz_logins(hostname, httpRealm); CREATE INDEX moz_logins_guid_index ON moz_logins(guid); CREATE INDEX moz_logins_encType_index ON moz_logins(encType); COMMIT;
La tabella moz_logins è costituita da 10 colonne. In dettaglio:
id - E' un identificatore univoco. Un numero maggiore di 0 che viene incrementato sequenzialmente salvando
una nuova password.
hostname - E' l'indirizzo del sito di cui si vuole memorizzare la password.
httpRealm - Non è mai stato popolato nelle mie prove. Negli esempi di sopra ha sempre il valore NULL che
corrisponde ad un campo di database non inizializzato.
formSubmitURL - E' l'indirizzo della maschera. Di solito coincide con hostname.
usernameField - E' il campo della maschera in cui deve essere inserito il nome utente.
passwordField - E' il campo della maschera in cui deve essere inserita la password.
encryptedUsername - E' il nome dell'utente utilizzato durante l'autenticazione criptato perchè non venga
letto da persone non autorizzate.
encryptedPassword - E' la password criptata utilizzata per autenticare l'utente.
guid - Un identificatore con formato {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
encType - Un valore pari a 1 implica che la password sia criptata.
Come eseguire la conversione
Prima di procedere si consiglia di eseguire un back-up della directory .mozilla contenuta nella home dell'utente per cui si desideri operare. Il modo più semplice per eseguire una copia è utilizzare il comando tar:
bash-4.1$ tar -jcf mozilla_bck.tar.bz2 .mozilla
In questo modo, nel caso qualcosa vada storto, sarà possibile ripristinare la situazione iniziale rimuovendo la directory nascosta .mozilla e scompattando l'archivio creato:
bash-4.1$ rm -r .mozilla bash-4.1$ tar -jxf mozilla_bck.tar.bz2
Si consiglia inoltre di accertarsi che Seamonkey sia chiuso durante l'esecuzione dell'importazione dei dati.
Trovare le directory contenenti il profilo dell'utente
Avendo sempre usato il solo profilo di default per il mio utente, la directory di interesse sarà /home/twinstar/.mozilla/default/<nome casuale> cioè: /home/twinstar/.mozilla/default/xt5ed1fd.slt/ per la versione 1.1.8 di Seamonkey. Tale directory conterrà i dati da migrare.
Avviando Seamonkey versione 2.0.x verrà automaticamente creata la nuova struttura di directory utilizzati per salvare i profili degli utenti: .mozilla/seamonkey/<nome casuale>.default/; .mozilla/seamonkey/8i3q7qe7.default/ nel mio caso. In tale directory dovranno essere migrati i dati. I file ivi contenuti inizialmente saranno ovviamente vuoti.
Configurare Seamonkey 2.0.x
Il passo successivo consiste nella configurazione di Seamonkey. Avviato il programma, bisognerà verificare che sia attiva l'impostazione di salvataggio delle password e procedere quindi ad impostare una "Master Password" uguale a quella utilizzata per la versione 1.1.x del prodotto.
Fatto ciò bisognerà sovrascrivere il file key3.db contenuto nel profilo della versione 2.0.x con una copia di quello esistente nel profilo della versione precedente.
A questo punto non resta che convertire le informazioni contenute nel file avente estensione *.s in istruzioni SQL da caricare nel database file signons.sqlite. La corrispondenza delle informazioni salvate nei due diversi formati sara':
id -> Un qualunque numero intero positivo. Eseguire un incremento per ogni riga. Si parte dal valore piu' alto salvato incrementato di una unita'. Se ad esempio il valore massimo fosse 5. Il primo numero da usare sarà 6. hostname -> Corrisponde alla prima riga del file xxxxxxx.s. httpRealm -> Impostare NULL. formSubmitURL -> Utilizzare il medesimo valore che per il campo hostname. usernameField -> Corrisponde alla seconda riga del file xxxxxxx.s. passwordField -> Corrisponde alla quarta riga del file xxxxxxx.s. encryptedUsername -> Corrisponde alla terza riga del file xxxxxxx.s. encryptedPassword -> Corrisponde alla quinta riga del file xxxxxxx.s. guid -> Se esistesse già una password copiarne il valore del campo guid altrimenti impostare NULL. encType -> Imporre il valore 1 che sta ad indicare una password criptata.
Le istruzioni SQL
A titolo di esempio verrà eseguita la conversione della password relativa al sito http://appdb.winehq.org contenuta nel file 52829682.s.
http://appdb.winehq.org sUserEmail MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC... *sUserPassword MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC... .
Supponendo che si tratti della quindicesima password inserita nell'elenco:
INSERT INTO "moz_logins" VALUES(15,'http://appdb.winehq.org',NULL,'http://appdb.winehq.org','sUserEmail', 'sUserPassword','MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC...','MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC...', '{c9158a9c-022c-4413-8b40-f843b5c8a5ec}',1);
Si noti che tutte le stringhe sono state racchiuse tra apici come richiesto dal linguaggio SQL per dati testuali. Si noti inoltre l'omissione non casuale dell'asterisco per la riga *sUserPassword. Per quanto concerne il campo guid si è utilizzato il valore di una password precedentemente inserita nell'elenco di SEamonkey 2.0.x. L'istruzione è stata terminata con il simbolo ";" come prevede lo standard del linguaggio SQL.
Per caricare la password sarà necessario digitare l'istruzione nel prompt del programma sqlite3 e premere invio:
bash-4.1$ sqlite3 signons.sqlite SQLite version 3.6.23.1 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> INSERT INTO "moz_logins" VALUES(15,'http://appdb.winehq.org',NULL,'http://appdb.winehq.org','sUserEmail', 'sUserPassword','MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC...','MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcEC...', '{c9158a9c-022c-4413-8b40-f843b5c8a5ec}',1); sqlite>
La password è stata così migrata e sarà disponibile al successivo avvio di Seamonkey. Per chiudere il programma sqlite3 digitare:
sqlite> .quit bash-4.1$
Note
Se si fosse importato per errore una password è possibile rimuoverla dall'elenco utilizzando l'istruzione:
sqlite> delete from "moz_logins" where id=<identificatore della password da eliminare>;
Inserire le password nel file signons.sqlite non è sufficiente per eseguire l'importazione. E' necessario anche copiare il file key3.db dal vecchio profilo. Senza tale file le password aggiunte saranno ignorate da Seamonkey.
E' caldamente consigliato operare a programma chiuso ed eseguire l'avvio solo a operazione conclusa per verificare il corretto funzionamento del sottosistema di gestione delle password.
La procedura proposta prevede di partire da un'installazione vergine del programma percio', se vi servisse preservare altri dati quali le e-mail o i bookmark, è necessario copiare i medesimi dal vecchio al nuovo profilo dell'utente.
Conclusione
Nel corso dell'articolo è stato esposto come vengano immagazzinate le password per diverse versioni del programma Seamonkey e come eseguire una migrazione manuale tra major release del prodotto. E' stato inoltre fornito un esempio di conversione di formato per una password. Chi necessitasse migrare molti dati ha due opzioni:
- Convertire le informazioni mediante l'ausilio di un editor di testo.
- Predisporre uno script che esegua la conversione in automatico producendo un file di testo in linguaggio SQL da utilizzare con sqlite3 od altro client SQL.
In qualunque modo si voglia procedere è sempre consigliato eseguire un back-up della sotto-directory .mozilla prima di qualsiasi altro passo.
Per commenti, consigli, domande inviate una e-mail all'indirizzo studiosg [chiocciola] giustetti [punto] net.
Link esterni
Lingue: English - Italiano