Created attachment 134698 [details] Backtrace of the crash I just got myself a new Hungarian eID card with digital signature capability. Using this client software: http://www.kekkh.gov.hu/Eszemelyi/letoltesek I managed to make the certificate appear in Firefox and LO on Ubuntu 14.04. The problem is that signing a simple ODT file using this certificate results in a crash with these lines on the console: warn:xmlsecurity.xmlsec:15335:1:xmlsecurity/source/xmlsec/errorcallback.cxx:48: xmltree.c:685: xmlSecAddIDs() '' '' 12 'invalid data for 'id': actual='idSignedProperties' and expected unique id (id already defined)' warn:xmlsecurity.xmlsec:15335:1:xmlsecurity/source/xmlsec/errorcallback.cxx:48: digests.c:207: xmlSecNssDigestVerify() 'sha256' '' 12 'data and digest do not match' GDB backtrace is attached.
is Gabor, is this issue still reproducible in master?
Most probably yes, we even tried to debug this during the Rome conference, but the attempt failed miserably when the card reader driver crashed on the laptop that had a debug LO available. :-(
I guess we can move it to NEW then...
New error message on the console, with the old 1.2.8 driver version: warn:xmlsecurity.xmlsec:26470:26470:xmlsecurity/source/xmlsec/errorcallback.cxx:48: x509vfy.c:253: xmlSecNssX509StoreVerify() 'x509-store' '' 71 'subject="CN=KELEMEN GÁBOR,serialNumber=IDCHU-393016BE,givenName=GÁBOR,SN=KELEMEN,C=HU"; reason=-8179' Different, but still crashes. I'll try the latest&greatest driver and post a new backtrace.
Created attachment 138591 [details] Fresh backtrace of the crash Fresh backtrace with the latest eID driver and current master build.
I don't think it is realistic to debug this remotely via bugzilla comments, but let me give this a try once: The interesting part from your backtrace is this: > Program received signal SIGSEGV, Segmentation fault. > 0x00007fffeb6d82b0 in SECKEY_GetPublicKeyType () from /home/gabor/src/core/instdir/program/libnss3.so > #0 0x00007fffeb6d82b0 in SECKEY_GetPublicKeyType () from /home/gabor/src/core/instdir/program/libnss3.so > #1 0x00007fffae5e49b3 in xmlSecNssKeyDataEcdsaGetType (data=0x7683fb0) at pkikeys.c:1463 xmlSecNssKeyDataEcdsaGetType() is "my" code in xmlsec; SECKEY_GetPublicKeyType() gets called just to assert that you you ask the "is this a public or a private+public key?" question with this function for an ecdsa key. Does it make any difference if you comment out that second assert? (Edit workdir/UnpackedTarball/xmlsec/src/nss/pkikeys.c:1463, i.e. comment out that line, make build-nocheck). I expect this is some corruption and it'll just crash a bit later at a different place if getting the type of a key causes a crash, but it is worth a try.
I commented out all asserts in that function, then there was no crash, but no successful signing either. This is the output on the console: warn:xmlsecurity.xmlsec:18310:18310:xmlsecurity/source/xmlsec/errorcallback.cxx:48: x509vfy.c:253: xmlSecNssX509StoreVerify() 'x509-store' '' 71 'subject="CN=KELEMEN GÁBOR,serialNumber=IDCHU-393016BE,givenName=GÁBOR,SN=KELEMEN,C=HU"; reason=-8179' warn:xmlsecurity.xmlsec:18310:18310:xmlsecurity/source/xmlsec/errorcallback.cxx:48: keysstore.c:267: xmlSecNssKeysStoreFindKeyFromSlot() '' 'name != NULL' 100 ' ' warn:xmlsecurity.xmlsec:18310:18310:xmlsecurity/source/xmlsec/errorcallback.cxx:48: keysstore.c:267: xmlSecNssKeysStoreFindKeyFromSlot() '' 'name != NULL' 100 ' ' warn:xmlsecurity.xmlsec:18310:18310:xmlsecurity/source/xmlsec/errorcallback.cxx:48: keysstore.c:267: xmlSecNssKeysStoreFindKeyFromSlot() '' 'name != NULL' 100 ' ' warn:xmlsecurity.xmlsec:18310:18310:xmlsecurity/source/xmlsec/errorcallback.cxx:48: keysstore.c:267: xmlSecNssKeysStoreFindKeyFromSlot() '' 'name != NULL' 100 ' ' warn:xmlsecurity.xmlsec:18310:18310:xmlsecurity/source/xmlsec/errorcallback.cxx:48: keys.c:1246: xmlSecKeysMngrGetKey() '' 'xmlSecKeysMngrFindKey' 1 ' ' warn:xmlsecurity.xmlsec:18310:18310:xmlsecurity/source/xmlsec/errorcallback.cxx:48: xmldsig.c:790: xmlSecDSigCtxProcessKeyInfoNode() '' '' 45 'details=NULL' warn:xmlsecurity.xmlsec:18310:18310:xmlsecurity/source/xmlsec/errorcallback.cxx:48: xmldsig.c:503: xmlSecDSigCtxProcessSignatureNode() '' 'xmlSecDSigCtxProcessKeyInfoNode' 1 ' ' warn:xmlsecurity.xmlsec:18310:18310:xmlsecurity/source/xmlsec/errorcallback.cxx:48: xmldsig.c:286: xmlSecDSigCtxSign() '' 'xmlSecDSigCtxSignatureProcessNode' 1 ' '
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6a069bea171a9857829d82711d16ec19621ff5f7 Related: tdf#109180 xmlsec nss: backport ecdsa fix It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This fixes the crash, but the functionality itself is still broken, let's keep the bug open.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fd1bc178b02e05cd12ec784ff87f5c97069bc5f5 tdf#109180 xmlsecurity nss: fix signing with ECDSA key It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 112104 has been marked as a duplicate of this bug. ***