Topic: Allegati firmati digitalmente .P7M

[klades]

Questo è un caso un po' diverso... potresti mandarmi un esempio di questo messaggio con allegati postacert.eml e daticert.xml (e con allegato alla PEC p7m ovviamente)?

Ok dovrei avertelo inviato, fammi sapere se ci sono problemi che non ti e' arrivato.

No, non mi è arrivato nulla fino a ora...

[crinoz]

Reinviato un altro. Strano perche' all'altra email, che ho messo come verifica di invio in copia carbone, era arrivata, forse un problema temporaneo a Virgilio.

[klades]

Ok, al secondo tentativo ho avuto la mail.
Per fare funzionare l'estensione anche in quel caso, bisogna lavorarci un po', mi ci metterò quando ho tempo....certo che è una faticaccia

[klades]

La versione 0.0.6 dovrebbe risolvere i problemi che si sono verificati con le precedenti e dovrebbe essere in grado di "svelare" anche gli allegati p7m contenuti in allegati EML.
Poi sicuramente facendo voi altri test, troverete altre cose che non vanno

@guia78: grazie per l'offerta, ma per fortuna al momento non ne ho bisogno

[guia78]

Lascio alcuni aspetti tecnici che sono stati riportati su un forum riguardo a questo problema. Spero servano a qualcosa.

Quanto alla correzione del problema, posto che la soluzione migliore dovrebbe venire dal team di mozilla, vedo che sull'altro forum siete arrivati a buon punto. Leggevo, però, di problemi con allegati corposi se la connessione va un po' a rilento, perchè l'email, allo stato attuale, dev'essere scaricata per intero prima dell'elaborazione anche con il protocollo IMAP. Forse la questione si potrebbe risolvere: il protocollo IMAP consente di accedere, su server, alle singole parti di una mail, ovvero alle singole sezioni mime senza scaricare il resto, quindi dovrebbe essere possibile accedere ai rispettivi header anche senza scaricare le sezioni corrispondenti; una gestione di questo tipo potrebbe richiedere una differenziazione esplicita tra l'accesso imap e quello pop3 nell'estensione che state realizzando, ed è realizzabile solo se TB espone le API relative a ciascun protocollo. Se non fosse possibile accedere agli header singolarmente, ma comunque l'accesso tramite imap consentisse l'accesso diretto alla sezione, si potrebbe scaricare un numero limitato di byte, in modo da ricostruire l'intestazione, o almeno ricavarne il content-type e il filename, per individuare un allegato p7m prima di procedere al download completo; in questo scenario è necessario implementare un parser minimale. Per il pop3 il problema non si pone, dato che l'intero contenuto viene scaricato in locale e cancellato dal server.

Altra cosa: leggevo di un problema con allegati misti, specialmente file non di testo. Forse avete già risolto; in caso contrario, credo che sarebbero opportune delle prove con il/i file .p7m in varie posizioni nell'elenco degli allegati, perchè, dal modo in cui era stato descritto, ho avuto l'impressione che il problema potesse essere relativo ad un qualche problema nell'elaborazione del primo p7m che renderebbe poi impossibile la gestione degli altri allegati. In questo scenario le cose si complicano, ma non troppo, posto che siano esposte le api necessarie a gestire un allegato di un certo tipo riconosciuto da TB. L'estensione dovrebbe comportarsi più o meno così:

- individuare il primo allegato p7m;
- creare l'elenco di tutti gli allegati a partire dal p7m, con i rispettivi header;
- gestire opportunamente ciascun allegato;

dove la gestione del singolo allegato dovrebbe avvenire in questo modo, se possibile:

- se l'allegato è un p7m, chiamare la routine specifica;

- in caso contrario:
--- istanziare il filtro predefinito di TB, scelto in base al content-type;
--- creare il menu contestuale relativo;

- aggiungere gli oggetti creati alla barra degli allegati.

Naturalmente, questo è possibile solo se thunderbird espone le api opportune, come dicevo prima, altrimenti diventa un lavoraccio, perchè bisognerebbe implementare a mano tutto (sarebbe un po' come creare un client di posta da zero, quindi non converrebbe).

Era buona, poi, l'idea di comunicare il problema al nuovo team che si occuperà dello sviluppo di tb, perchè da li deve venire la soluzione definitiva. Non servono poi molti dettagli tecnici, basta descrivere il modo in cui riprodurre il bug, cioè, fondamentalmente, inviare un allegato .p7m che sicuramente non potranno aprire, ed eventualmente accennare al problema con allegati di tipo misto, se confermato. Comunque, mi sa che la discussione così finisce un po' troppo OT

Spero che i miei suggerimenti possano esservi utili

[crinoz]

La versione 0.0.6 dovrebbe risolvere i problemi che si sono verificati con le precedenti e dovrebbe essere in grado di "svelare" anche gli allegati p7m contenuti in allegati EML.
Poi sicuramente facendo voi altri test, troverete altre cose che non vanno

Confermo il funzionamento della versione 0.0.6 
Testato sia negli allegati EML che non, su XP e Vista.
Bel lavoro Klades

Se avete altre versioni da testare, sono qui

[klades]

Quanto alla correzione del problema, posto che la soluzione migliore dovrebbe venire dal team di mozilla, vedo che sull'altro forum siete arrivati a buon punto. Leggevo, però, di problemi con allegati corposi se la connessione va un po' a rilento, perchè l'email, allo stato attuale, dev'essere scaricata per intero prima dell'elaborazione anche con il protocollo IMAP. Forse la questione si potrebbe risolvere: il protocollo IMAP consente di accedere, su server, alle singole parti di una mail, ovvero alle singole sezioni mime senza scaricare il resto, quindi dovrebbe essere possibile accedere ai rispettivi header anche senza scaricare le sezioni corrispondenti; una gestione di questo tipo potrebbe richiedere una differenziazione esplicita tra l'accesso imap e quello pop3 nell'estensione che state realizzando, ed è realizzabile solo se TB espone le API relative a ciascun protocollo.
Se non fosse possibile accedere agli header singolarmente, ma comunque l'accesso tramite imap consentisse l'accesso diretto alla sezione, si potrebbe scaricare un numero limitato di byte, in modo da ricostruire l'intestazione, o almeno ricavarne il content-type e il filename, per individuare un allegato p7m prima di procedere al download completo; in questo scenario è necessario implementare un parser minimale. Per il pop3 il problema non si pone, dato che l'intero contenuto viene scaricato in locale e cancellato dal server.

Per quanto riguarda il team di sviluppo di Mozilla, se ne è già parlato, quindi inutile ripetersi.
Per quanto riguarda lo scaricamento da IMAP, credo che quello che dici sia esatto solo in parte: infatti è vero che il protocollo IMAP consente lo scaricamento "a pezzi", anzi questo sistema è usato di default da TB (infatti vedi prima il testo degli allegati).
Non puoi però accedere "direttamente" alle sezioni degli header...infatti come si farebbe a individuare le sezioni senza scaricare tutto il messggio?
Anche lo scaricamento di pochi byte non risolve il problema: immagina uno scenario con una mail con un allegato molto lungo "normale" e poi un "p7m" alla fine, in questo caso devi per forza fare il parser di tutto il testo.
In realtà TB mette a disposizione delle funzioni che fanno un parser degli header degli allegati (fatto in C è ovviamente molto più veloce), il problema è che queste funzioni native "saltano" gli allegati p7m e quindi ritorniamo al punto di partenza.
Ripeto, la soluzione migliore sarebbe consentire la disabilitazione del supporto integrato SMIME, ma questo si può fare solo a livello di sorgente.

Altra cosa: leggevo di un problema con allegati misti, specialmente file non di testo. Forse avete già risolto; in caso contrario, credo che sarebbero opportune delle prove con il/i file .p7m in varie posizioni nell'elenco degli allegati, perchè, dal modo in cui era stato descritto, ho avuto l'impressione che il problema potesse essere relativo ad un qualche problema nell'elaborazione del primo p7m che renderebbe poi impossibile la gestione degli altri allegati.

Non ho studiato bene il problema e sinceramente non posso neanche passare la vita a studiare come funziona TB...tranne che Mozilla mi assuma e mi paghi a sufficienza
A occhio direi che c'è un problema nel parser nativo di TB che a volte - in presenza di allegati normali e p7m - non riesce a individuarne correttamente i confini, ma posso sbagliare.
Comunque è problema che non si può affrontare a livello di estensione.

Confermo il funzionamento della versione 0.0.6 
Testato sia negli allegati EML che non, su XP e Vista.
Bel lavoro Klades
Se avete altre versioni da testare, sono qui

Grazie!
Comunque quello che c'è da testare è la routine base dell'estensione, cioè se riesce a individuare correttamente gli allegati e salvarli.
Quindi la cosa più utile e testarla con vari messaggi, per trovare eventuali bug.
Una volta arrivato ad avere un "cuore" funzionante, penso di aggiungere un paio di cosette:
- una modalità di funzionamento non automatica - a richiesta - in modo da evitare sprechi di risorse laddove non serve;
- un'opzione per aprire l'allegato con un'applicazione a scelta dell'utente.

[Lucas Malor]

Dunque, mi sono fatto mandare una mail da Crinoz e tutto funziona a meraviglia con l'estensione, a parte qualche problema di GUI. L'allegato viene segnalato, lo si puo' salvare e visualizzare.

Ci sono altre prove che posso fare?

In firma ho messo la mia configurazione software - hardware, cosi' non devo postarla ogni volta

PS: klades, potresti aggiornare la versione dell'estensione? Cosi' si puo' chiedere a qualcuno se usa l'ultima versione.

[crinoz]

Grazie!
Comunque quello che c'è da testare è la routine base dell'estensione, cioè se riesce a individuare correttamente gli allegati e salvarli.
Quindi la cosa più utile e testarla con vari messaggi, per trovare eventuali bug.

Per adesso l'ho testato con circa 8 messaggi diversi su 2 pc diversi con 2 sistemi operativi

Una volta arrivato ad avere un "cuore" funzionante, penso di aggiungere un paio di cosette:
- una modalità di funzionamento non automatica - a richiesta - in modo da evitare sprechi di risorse laddove non serve;
- un'opzione per aprire l'allegato con un'applicazione a scelta dell'utente.

l'opzione "apri con" sarebbe splendida in effetti

[guia78]

Bene bene. Chi volesse ricevere o inviarmi allegati firmati digitalmente me lo chieda in privato!

[Lucas Malor]

Un suggerimento ragazzi: ho letto in giro che i problemi possono sorgere anche a seconda del client che ha inviato la mail, e non solo a causa di chi la riceve. Quindi indicate con che client inviate le mail.

Ultima cosa, sulle FAQ ufficiali c'e' qualcosina su S/MIME.

[xeal]

Salve a tutti! Mi intrometto nella discussione, essendo io l'autore del post riportato da guia78

Per quanto riguarda il team di sviluppo di Mozilla, se ne è già parlato, quindi inutile ripetersi.
Per quanto riguarda lo scaricamento da IMAP, credo che quello che dici sia esatto solo in parte: infatti è vero che il protocollo IMAP consente lo scaricamento "a pezzi", anzi questo sistema è usato di default da TB (infatti vedi prima il testo degli allegati).
Non puoi però accedere "direttamente" alle sezioni degli header...infatti come si farebbe a individuare le sezioni senza scaricare tutto il messggio?
Anche lo scaricamento di pochi byte non risolve il problema: immagina uno scenario con una mail con un allegato molto lungo "normale" e poi un "p7m" alla fine, in questo caso devi per forza fare il parser di tutto il testo.
In realtà TB mette a disposizione delle funzioni che fanno un parser degli header degli allegati (fatto in C è ovviamente molto più veloce), il problema è che queste funzioni native "saltano" gli allegati p7m e quindi ritorniamo al punto di partenza.
Ripeto, la soluzione migliore sarebbe consentire la disabilitazione del supporto integrato SMIME, ma questo si può fare solo a livello di sorgente.

Che io sappia, un messaggio multipart su protocollo IMAP viene gestito, lato server, come una specie di database (o meglio, come un albero: si pensi a una directory che consente l'accesso diretto ai singoli file). Forse non è possibile ottenere informazioni dirette sull'header di una singola sezione, però, che io sappia (non ci ho mai messo le mani nella pratica), è possibile accedere ad una sezione saltando le altre, basandosi sui boundary. L'intestazione, se non sbaglio, può anche essere assente (specialmente per contenuti testuali con charset di base), ma se è presente, sempre se non sbaglio, sta all'inizio, subito dopo il boundary e prima del contenuto, quindi dicevo che si dovrebbe poter fare quanto segue: posizionarsi all'inizio della sezione, scaricare alcuni byte in una stringa per interpretare il content-type e/o il filename, scaricare il resto se la sezione è quella cercata (o una di quelle cercate), quindi posizionarsi all'inizio della sezione successiva, saltando il contenuto intermedio se non corrispondeva al target della ricerca. Se poi le api per le estensioni di TB non consentono di saltare una sezione senza scaricarla il discorso cambia...

Non ho studiato bene il problema e sinceramente non posso neanche passare la vita a studiare come funziona TB...tranne che Mozilla mi assuma e mi paghi a sufficienza 
A occhio direi che c'è un problema nel parser nativo di TB che a volte - in presenza di allegati normali e p7m - non riesce a individuarne correttamente i confini, ma posso sbagliare.
Comunque è problema che non si può affrontare a livello di estensione.

Però potrebbe essere interessante segnalarlo se verificato, dicevo di fare qualche prova anche solo per questo: niente di trascendentale, solo prendere un paio di file, con i quali possibilmente si è verificato il problema, e spedirli come allegati due volte in ordine inverso (tipo nella prima mail allego prima un .doc e come secondo allegato un .p7m, e nella seconda li inverto, così mi accorgo se la mancata notifica dell'allegato è determinata effettivamente dalla presenza del p7m in una posizione precedente dell'elenco degli allegati). Il resto, effettivamente, può essere un lavoraccio, specialmente se TB non espone qualche funzione nativa utile allo scopo 

[Lucas Malor]

Aaaaaah, ho trovato una cosa molto interessante. Sembrerebbe che alcuni server SMTP cancellino gli spazi vuoti alla fine di una mail, e questo puo' invalidare la chiave.

Per ovviare a questo problema si era proposto di cancellare i caratteri vuoti alla fine di una mail crittata prima di inviarla. Non capisco perche' ancora non l'abbiano fatto, mi pare semplice: basta cancellare qualsiasi carattere di tab, space, carriage return, line feed o di NULL alla fine della mail.

Vi linko anche la relativa discussione su Bugzilla.

EDIT: tra l'altro qualcuno ha segnalato che capitano problemi anche quando c'e' il carattere £ nel testo del messaggio. Ho provato a spedirmi una mail con allegato crittato tramite Gmail, ma tutto funziona. Comunque anche questo potrebbe dipendere dal server SMTP. Vi linko anche quest'altra discussione.


@xeal: mi pare abbiano provato anche con POP3, quindi non e' un problema di IMAP EDIT: e mi pareva male

[xeal]

Un suggerimento ragazzi: ho letto in giro che i problemi possono sorgere anche a seconda del client che ha inviato la mail, e non solo a causa di chi la riceve. Quindi indicate con che client inviate le mail.

Ultima cosa, sulle FAQ ufficiali c'e' qualcosina su S/MIME.

Il supporto a S/Mime è inevitabilmente influenzato dalla corretta gestione dei certificati, al punto che la cancellazione di un certificato scaduto e sostituito con un altro contenente le stesse identiche chiavi impedirebbe comunque la decodifica dei messaggi creati con il certificato precedente, quindi è possibile che ci sia un legame con i problemi descritti nelle faq. Però, un problema simile dovrebbe riguardare principalmente la lettura e la creazione di messaggi firmati direttamente da tb, quindi confermerebbe che tb cerca di interpretare l'allegato e di verificare i certificati, e se non ci riesce non rende disponibile l'allegato (oppure si verifica un errore che fa saltare l'operazione). Se tutto si riducesse ad una questione di certificati considerati non validi, dovrebbe essere facile verificarlo con la procedure illustrata nel link, e, una volta (ri)abilitati i certificati, dovrebbe essere possibile vedere e gestire correttamente gli allegati .p7m; sono però un po' scettico, visto che, a quanto pare, possono verificarsi dei problemi anche con gli altri allegati della mail, quindi dovrebbe trattarsi di un vero e proprio bug nel supporto a s-mime, contrariamente a quanto dichiarato nelle faq.

Se, incece, fosse questo il caso, allora il compito dell'estensione potrebbe essere molto semplificato, sempre a condizione che si possa accedere a certe funzioni: "basterebbe" intercettare una qualsiasi modifica ai certificati, creare un backup del loro stato e ripristinarlo subito dopo la modifica (tranne, ovviamente per i certificati modificati), verificando che la modifica effettuata (in particolare, l'inserimento di un certificato) abbia avuto luogo correttamente. Naturalmente, questo avrebbe delle conseguenze estreme: risolvere del tutto il problema via estensione, MA, costringere il buon klades a riscriverla da capo per fare qualcosa di completamente diverso, quindi probabilmente vorrà eliminarmi per averlo suggerito    

[xeal]

@Lucas Malor

Se poi avviene anche una modifica del contenuto che invalida la chiave, be', allora mi sa che c'è poco da fare, se non disabilitare il supporto a S/MIME, ma questo può farlo solo il team degli sviluppatori. Tuttavia, ho qualche dubbio, perchè se la firma venisse invalidata, allora non dovrebbe essere possibile leggere il messaggio, una volta scaricato, con programmi come dike, nè verificarlo con i programmi cui si era accennato nelle pagine precedenti (gli allegati non visti che sono stati testati superavano la verifica ed erano leggibili, no?), a meno che quei programmi non ignorino automaticamente quel tipo di discrepanza, ma mi sembra un po' strano... poi non so...


EDIT. Ho letto meglio quei bug-report, e non dovrebbero essere validi in questo caso: gli allegati vengono criptati e firmati a parte, quindi inseriti inseriti nel messaggio con un opportuno transfer encoding (per quello che ho visto nelle prime pagine del thread, è sempre base64), in questo modo nessun carattere può essere eliminato dal contenuto e la firma digitale resta valida. Dovrebbe essere lo stesso per il carattere "£".

EDIT 2. Per il discorso sull'IMAP: si era accennato a qualche problema di lentezza dell'estensione in presenza di allegati "ingombranti", perchè vengono scaricati per intero prima dell'elaborazione, e così se la connessione al server va a rilento ci vuole un po' di tempo prima che l'allegato risulti visibile, qiundi ho provato a suggerire una possibile soluzione per il caso specifico, tutto qui

Nel caso del pop3 la questione è trascurabile, perchè le mail sono scaricate per intero dal client di posta prima di essere rese disponibili.