Rimozione BOM da P7M - FileSdIConMetadati

[fednikx]

Ciao!
Sto utilizzando con successo le vostre due classi.

Il problema che riscontro è alquanto bizzarro: quando ricevo un file prodotto dal gestionale Zucchetti o da Aruba stessa, il supporto ricevuto dall'oggetto FileSdIConMetadati presenta un hash diverso da quello dichiarato nei corrispondenti metadati risultando corrotto. Si tratta di file firmati CAdES-BES con estensione p7m. Sono effettivamente corrotti in quanto nè openssl nè altri tools rilevano un p7m valido e differiscono da quelli che vengono successivamente salvati sul portale F&C.

[fednikx]

Il problema è la rimozione del BOM dal p7m, il che invalida la firma ed il controllo hash.
file corrotto:

file corretto:

[SorPampurio]

Ho avuto lo stesso problema. Il discorso del BOM dovrebbe verificarsi sono in caso di invio del file XML (ma forse neanche, dato che ricevo fatture con il BOM presente anche se firmate), quindi in recezione non ha senso toglierlo, almeno non prima di aver verificato che il file non sia firmato.

Controllare se il file è firmato usando il filename è errato a sua volta, in quando non considera il formato xades od un uso errato dell'estensione p7m.

[fednikx]

Sono assolutamente d'accordo con te infatti sul mio altro canale SDIFTP il BOM lo rimuovo solo dopo aver verificato la firma e solo ai fini di elaborare correttamente l'xml (per dire, a livello di db il BOM è salvato).
Onestamente non so perchè questa classe utilizzi removeBOM() (non sono stato ad analizzarla nel dettaglio). Ho introdotto il controllo sull'estensione come workaround temporaneo, è chiaro che il tutto andrebbe fatto meglio.
Il problema dell'uso errato dell'estensione non dovrebbe esserci in quanto SDI dovrebbe respingere un p7m non correttamente firmato CaDES...
Naturalmente non bisogna mai fidarsi dell'input, mi sono semplicemente limitato a modificare la classe di modo che non mi corrompesse i p7m.

[fednikx]

Ho avuto lo stesso problema. Il discorso del BOM dovrebbe verificarsi sono in caso di invio del file XML (ma forse neanche, dato che ricevo fatture con il BOM presente anche se firmate), quindi in recezione non ha senso toglierlo, almeno non prima di aver verificato che il file non sia firmato.

Controllare se il file è firmato usando il filename è errato a sua volta, in quando non considera il formato xades od un uso errato dell'estensione p7m.

Dopo aver avuto l'ennesimo controllo hash fallito su di un xml ho deciso di eliminare definitivamente removeBOM(). Sarebbe interessante sapere da @aded perchè sia stato scelto di inserire questa funzione in ricezione. 😬

[aded]

Ciao @fednikx grazie per la segnalazione e la PR. Do un'occhiata quanto prima e faccio merging della PR.

[bago]

Concordo anche io che quel removeBom non dovrebbe esserci:
https://github.com/taocomp/php-sdicoop-server/blob/master/src/FileSdIBase.php#L69

Nel mio caso ho scoperto che i file p7m ricevuti erano quasi tutti "invalidi" e non verificabili, poi scaricandoli dal sito Fatture dell'AdE riuscivo invece ad elaborarli e dopo vari controlli ho visto che mancavano sempre quei 3 byte del BOM e alla fine sono arrivato a quella riga di codice che li toglie "volontariamente", rompendo così i file p7m con BOM (e mi pare che molti di quelli che firmano le B2B mettano anche il BOM).

[brainssolutions]

@aded ci sono novità su questa segnalazione ?