Le istruzioni riportate nel readme non sono piu attuali

[amusarra]

Branch: master Sistema Operativo: Raspberry Pi OS Architettura: ARM

Su questa nuova versione la build si rompe quasi subito al lancio del comando meson builddir libs a causa dell'errore libs/meson.build:11:0: ERROR: C++ shared or static library 'libpodofo' not found (vedi immagine a seguire).

La precedente versione (1.4.1) non aveva questo problema. Compilazione su ARM (RPI 4).

Ho visto che c'è stato ulteriore refactoring, andrebbe revisionato il README; il comando di build indicato non è più valido a causa del fatto che la directory libcie-pkcs11 non esiste più. È possibile che per la Build Generica occorre procedere in modo diverso che al momento non è indicato?

Grazie.

[M0Rf30]

Ciao @amusarra ciò è dovuto al fatto che ho isolato la libreria in un archivio tra le release. Non è buona pratica caricare blob in repo sorgente

Prima di meson procedi da root del repo con

curl -sL "https://github.com/M0Rf30/cie-middleware-linux/releases/download/podofo-1.4.2/libpodofo-1.4.2.tar.gz" -o libpodofo.tar.gz
tar xf libpodofo.tar.gz --directory=libs/lib

dovrebbe partire senza problemi. purtroppo, per via di questa libreria fornita senza sorgenti, non è possibile parlare neanche di progetto open.

La compilazione con libpodofo vanilla non è possibile come riportato anche qui https://github.com/italia/cie-middleware/issues/87

in quanto mancano dei simboli. penso che tu debba trovare un escamotage su arm

[amusarra]

Ciao @M0Rf30, grazie si avevo infatti ipotizzato. Adesso sto facendo la build di cryptopp. Mi chiedo una cosa. Se cryptopp è una dipendenza obbligatoria, come mai meson termina correttamente? Forse perché di Runtime?

Non capisco inoltre perché mi dia XML2 mancante anche se in realtà è installato sul sistema.

[M0Rf30]

se noti c'è una doppia dichiarazione: una come libcrypto++ (risolta) l'altra è libcryptopp.

Purtroppo la risoluzione del nome libreria non è sempre la stessa tra distro. in questo caso si è presentata questa evenienza, in particolar modo tra Arch Linux e Debian-based. spulciando in giro questo è buon modo per risolvere.

stesso ragionamento per xml2. infatti non dovrebbe fallire la build. hai libxml-2.0 e xml2 (non risolta)

[amusarra]

In realtà libxml-2.0 è risolta come puoi vedere dall'immagine precedente, quella non risolta, "stranamente" è xml2. Ti faccio sapere non appena finirò di compilare libcryptopp.

[M0Rf30]

non è strano. dipende dal pkgconfig della libreria e da come è dichiarato il nome di essa sulla tua distro, a volte ci sono leggere differenze di nomenclatura. forse il mio approccio può essere migliorato nel meson file (anzi, sicuramente), ma non ho approfondito.

[amusarra]

Ciao @amusarra ciò è dovuto al fatto che ho isolato la libreria in un archivio tra le release. Non è buona pratica caricare blob in repo sorgente

Prima di meson procedi da root del repo con

curl -sL "https://github.com/M0Rf30/cie-middleware-linux/releases/download/podofo-1.4.2/libpodofo-1.4.2.tar.gz" -o libpodofo.tar.gz
tar xf libpodofo.tar.gz --directory=libs/lib

dovrebbe partire senza problemi. purtroppo, per via di questa libreria fornita senza sorgenti, non è possibile parlare neanche di progetto open.

La compilazione con libpodofo vanilla non è possibile come riportato anche qui italia/cie-middleware#87

in quanto mancano dei simboli. penso che tu debba trovare un escamotage su arm

Su ARM infatti ottengo l'errore /usr/bin/ld: /home/amusarra/progetti/sources/cie-middleware-linux/libs/lib/libpodofo.a: error adding symbols: file in wrong format in quando libpodofo.a è per x86. Anche compilando dai sorgenti su ARM non funzionerebbe a causa di quanto riportato sulla issue da te indicata.

A questo punto la vedo dura, dovrei compilare podofo con la patch fatta da loro. Comunque è assurdo com'è stato realizzato il progetto. Volevo fare una cosa carina ma mi stanno facendo passare la voglia.

Grazie in ogni caso per il tuo supporto.

[M0Rf30]

puoi provare a dare un occhio nel diff tra tag 1.4.2 e 1.4.1 se non ti occorre la firma e disabilitare le chiamate a podofo. oppure fare qualche prova con qemu-static e binfmt. in ogni caso trovi il changelog, come vedi le novità non sono molto significative

[M0Rf30]

ho provato a fare un po di reversing e ho ottenuto una draft di quello che fa SetGraphometricData

andrebbe posizionato nel file sorgente di podofo ./src/podofo/doc/PdfSignatureField.cpp

 // this is a call example within libs/sign-sdk/src/PdfSignatureGenerator.cpp  
 // SetGraphometricData(PdfString("Aruba_Sign_Biometric_Data"), PdfString(szGraphometricData), PdfString(szVersion));
    void PdfSignatureField::SetGraphometricData(const PdfString &rsGraphometricDataName,
                                                const PdfString &rsGraphometricData,
                                                const PdfString &rsVersion)
    {
        PdfError *this;
        long in_FS_OFFSET;
        undefined4 local_a8[34];
        undefined8 local_20;

        local_20 = *(undefined8 *)(in_FS_OFFSET + 0x28);
        if (*(long *)(param_1 + 0x20) == 0)
        {
            this = (PdfError *)__cxa_allocate_exception(0x60);
            local_a8[0] = 2;
            /* WARNING: Subroutine does not return */
            /* try { // try from 00102ed7 to 00102edb has its CatchHandler @ 00103122 */
            PoDoFo::PdfError::PdfError(this, (EPdfError *)local_a8,
                                       "/home/piero/Desktop/IPZS/podofo-0.9.1/src/doc/PdfSignatureField.cpp", 0x145,
                                       (char *)0x0);
        }
        /* WARNING: Subroutine does not return */
        PdfVariant::GetDictionary(*(PdfVariant **)(param_1 + 0x20));
    }

se è solo per la firma grafica puoi commentare libs/sign-sdk/src/PdfSignatureGenerator.cpp:188 e usare podofo vanilla

[amusarra]

Ho ricompilato la versione 0.9.1 di podofo su ARM e commentato su PdfSignatureGenerator le parti per cui non trova i simboli, per i miei scopi non mi serve.

Ho modificato il file meson di build è aggiunta la riga add_global_link_arguments('-ljpeg', language: 'cpp') per evitare i vari errori undefined reference tojpeg_*`. Fatto questo la build è andata a buon fine.

Adesso non resta altro che provare se libcie-pkcs11.so funzioni correttamente.

[M0Rf30]

Sarei curioso di sapere se funziona questa 1.4.2. tienimi aggiornato se possibile. per libjpeg molto strano. indagherò

[amusarra]

Allora, ho provato a usare il programma TestCIE, che fa una serie di test suite (che funziona correttamente su x86), compilato in questo modo g++ -o TestCIE TestCIE.cpp UUCByteArray.cpp -ldl -g . Una volta lanciato ed eseguito il primo test, va in Segmentation Fault 😮‍💨 Con il debugger ho questo stacktrace. Al momento mi fermo, sono stanco, sto faticando un botto e nottate per una cosa che immaginavo fosse semplice, come dovrebbe essere. Se a te può venir in mente qualcosa, ben venga.

Load Module libcie-pkcs11.so
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x0000007ff734dde8 in CryptoPP::CPU_ProbePMULL() () from /lib/aarch64-linux-gnu/libcrypto++.so.8
(gdb) bt
#0  0x0000007ff734dde8 in CryptoPP::CPU_ProbePMULL() () from /lib/aarch64-linux-gnu/libcrypto++.so.8
#1  0x0000007ff7261848 in CryptoPP::DetectArmFeatures() () from /lib/aarch64-linux-gnu/libcrypto++.so.8
#2  0x0000007ff7fdac9c in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7ffffff3f8, env=env@entry=0x7ffffff408) at dl-init.c:72
#3  0x0000007ff7fdada4 in call_init (env=0x7ffffff408, argv=0x7ffffff3f8, argc=1, l=<optimized out>) at dl-init.c:30
#4  _dl_init (main_map=0x555557f5e0, argc=1, argv=0x7ffffff3f8, env=0x7ffffff408) at dl-init.c:119
#5  0x0000007ff7d55b14 in __GI__dl_catch_exception (exception=0x0, operate=0x7ff7fde130 <call_dl_init>, args=0x7fffffe510) at dl-error-skeleton.c:182
#6  0x0000007ff7fded28 in dl_open_worker (a=a@entry=0x7fffffe760) at dl-open.c:758
#7  0x0000007ff7d55ab4 in __GI__dl_catch_exception (exception=0x7fffffe748, operate=0x7ff7fde9b0 <dl_open_worker>, args=0x7fffffe760) at dl-error-skeleton.c:208
#8  0x0000007ff7fde610 in _dl_open (file=0x5555559900 "libcie-pkcs11.so", mode=-2147483647, caller_dlopen=0x5555554460 <main(int, char**)+608>, nsid=-2, argc=1, argv=0x7ffffff3f8, env=0x7ffffff408) at dl-open.c:837
#9  0x0000007ff7fb9264 in dlopen_doit (a=a@entry=0x7fffffea18) at dlopen.c:66
#10 0x0000007ff7d55ab4 in __GI__dl_catch_exception (exception=exception@entry=0x7fffffe9a0, operate=0x7ff7fb9200 <dlopen_doit>, args=0x7fffffea18) at dl-error-skeleton.c:208
#11 0x0000007ff7d55b80 in __GI__dl_catch_error (objname=0x7ff7fcb0c8 <last_result+16>, errstring=0x7ff7fcb0d0 <last_result+24>, mallocedp=0x7ff7fcb0c0 <last_result+8>, operate=<optimized out>, args=<optimized out>)
    at dl-error-skeleton.c:227
#12 0x0000007ff7fb9b10 in _dlerror_run (operate=operate@entry=0x7ff7fb9200 <dlopen_doit>, args=args@entry=0x7fffffea18) at dlerror.c:170
#13 0x0000007ff7fb9304 in __dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:87
#14 0x0000005555554460 in main (argc=1, argv=0x7ffffff3f8) at TestCIE.cpp:794
(gdb)

[M0Rf30]

Si immagino, ho espresso anche upstream la mia frustrazione. Vedrò cosa posso fare per sistemare le cose. Nel frattempo ho caricato un branch qui https://github.com/M0Rf30/cie-middleware-linux/tree/podofo-vanilla sostanzialmente uso le lib e gli header vanilla e evito la parte di "decorazione grafica" del documento. Se ti va di farci un giro.... Onestamente non farei affidamento sui test, ma farei una prova pratica. con firefox o chrome (modutil)

[amusarra]

Appena posso vedrò il branch, grazie. In realtà il TestCIE è pratico, uno dei test è appunto il login sulla CIE via PIN code. Per il mio caso d'uso non mi serve il funzionamento con il browser (sul raspberry infatti non il desktop proprio installato). Il mio obiettivo è far funzionare il tutto per poi realizzare un sistema di accesso basato su CIE, così come ho fatto per la CNS e l'ultimo su questo articolo Raspberry Pi e Smart Card Mifare Classic 1K: Realizzare un sistema di accesso. Nel caso della CIE come anche già fatto per la CNS, utilizzerei un keypad connesso al Raspberry per inserire il PIN nel caso fosse corretto, verifico la validità del certificato e solo dopo "aprire la porta".

[rnhmjoj]

Onestamente non farei affidamento sui test, ma farei una prova pratica. con firefox o chrome (modutil)

Allora, ho appena finito di scrivere un bel pacchetto Nix che fa una build riproducibile di cie-middleware-linux usando il branch con podofo originale. Ho provato le seguenti cose:

1. abbinare la carta;
2. firmare e verificare la firma (sia CAdES sia PAdES);
3. aggiungere il modulo PKCS#11 al database NSS e fare un login;
4. rimuovere la carta.

Sembra funzionare tutto correttamente tranne la firma PAdES. Se spunto "aggiungi la firma grafica" la firma fallisce con questo errore (che sembra essere un'incompatibilità tra ghost4j e jna):

Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: Invalid calling convention 63
    at com.sun.jna.Native.createNativeCallback(Native Method)
    at com.sun.jna.CallbackReference.<init>(CallbackReference.java:320)
    at com.sun.jna.CallbackReference.getFunctionPointer(CallbackReference.java:506)
    at com.sun.jna.CallbackReference.getFunctionPointer(CallbackReference.java:483)
    at com.sun.jna.Function.convertArgument(Function.java:558)
    at com.sun.jna.Function.invoke(Function.java:345)
    at com.sun.jna.Library$Handler.invoke(Library.java:265)
    at jdk.proxy2/jdk.proxy2.$Proxy3.gsapi_set_stdio(Unknown Source)
    at org.ghost4j.Ghostscript.initialize(Ghostscript.java:323)
    at org.ghost4j.renderer.SimpleRenderer.run(SimpleRenderer.java:105)
    at org.ghost4j.renderer.AbstractRemoteRenderer.render(AbstractRemoteRenderer.java:86)
    at org.ghost4j.renderer.AbstractRemoteRenderer.render(AbstractRemoteRenderer.java:70)
    at it.ipzs.cieid.Firma.PdfPreview.<init>(PdfPreview.java:53)
    at it.ipzs.cieid.MainFrame$42.actionPerformed(MainFrame.java:2033)

Senza mettera la spunta il programma invece crasha

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fbe441740b0, pid=2393655, tid=2393968
#
# JRE version: OpenJDK Runtime Environment (17.0.4+8) (build 17.0.4+8-nixos)
# Java VM: OpenJDK 64-Bit Server VM (17.0.4+8-nixos, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [libpodofo.so.0.9.8+0x14e0b0]  PoDoFo::PdfPagesTree::GetTotalNumberOfPages() const+0x0
#

Un'altra cosa è che ho dovuto patchare un sacco di headers in modo da includere PCSC/wintypes.h prima degli altri header di PCSC. Non so per quale motivo ma altrimenti varie typedef che sono usate nell'API non vengono trovati.

Comunque, ottimo lavoro, grazie.

[ceztko]

Segnalo anche qui, come già fatto nell'altro issue, che la versione master (e la futura 1.0.0) di PoDoFo ha una API totalmente rinnovata per la firma, oltre che a una sterminata quantità di bugfix e nuove features.

[M0Rf30]

Segnalo anche qui, come già fatto nell'altro issue, che la versione master (e la futura 1.0.0) di PoDoFo ha una API totalmente rinnovata per la firma, oltre che a una sterminata quantità di bugfix e nuove features.

Grazie per la segnalazione, ma non vedo ancora un tag/release per la 1.0.0. Su altri branch ho provato l'upgrade alla 0.10.0, ma non sono esattamente un drago del C e i miei tentativi non hanno avuto successo. Farò altre prove non appena la 1.0.0 è taggata.

[ceztko]

Confermo, la 1.0.0 non è ancora taggata, sebbene il master sia già in questo momento ampiamente testato e non immagino cambiamenti per le funzioni più comuni e per la firma. Appena sarà terminato il processo di review della API di PoDoFo (una cosa che dura ormai da almeno un paio di anni) allora probabilmente taggherò una beta.