Bug 66701 - PDF: Malfunctioning PDF's digital signature function.
Summary: PDF: Malfunctioning PDF's digital signature function.
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.4.2 release
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: BSA target:4.4.0 target:4.3.3
Keywords:
Depends on:
Blocks: PDF-Signature
  Show dependency treegraph
 
Reported: 2013-07-08 14:41 UTC by Tamas Domjan
Modified: 2014-12-05 12:40 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Created by LibreOffice (31.53 KB, application/force-download)
2013-07-08 14:41 UTC, Tamas Domjan
Details
Created by PDF Creator print driver from LibO (13.13 KB, application/force-download)
2013-07-08 14:42 UTC, Tamas Domjan
Details
gdb output segfault (8.46 KB, text/plain)
2014-09-09 10:38 UTC, Markus Wernig
Details
gdb output 4.2.6.2 double free or corruption (fasttop) (86.44 KB, text/plain)
2014-09-09 10:41 UTC, Markus Wernig
Details
gdb output 4.2.6.2 segfault (12.06 KB, text/plain)
2014-09-09 10:44 UTC, Markus Wernig
Details
gdb output 4.2.6.2 corrupted double-linked list (86.08 KB, text/plain)
2014-09-09 10:45 UTC, Markus Wernig
Details
test document (8.30 KB, application/vnd.oasis.opendocument.text)
2014-09-09 10:52 UTC, Markus Wernig
Details
gdb output 4.3.1.2 double free or corruption (fasttop) (127.96 KB, text/plain)
2014-09-09 10:59 UTC, Markus Wernig
Details
valgrind trace LO 4.2.6. 2 not starting (508.98 KB, text/plain)
2014-09-12 10:44 UTC, Markus Wernig
Details
valgrind trace LO 4.3.1.2 not crashing (1.34 MB, text/plain)
2014-09-12 10:45 UTC, Markus Wernig
Details
valgrind trace LO 4.3.1.2 crashing (2.49 MB, text/plain)
2014-09-12 10:45 UTC, Markus Wernig
Details
PDF signature OK (23.73 KB, application/octect-stream)
2014-09-14 18:44 UTC, Markus Wernig
Details
PDF/A signature OK (35.60 KB, application/octect-stream)
2014-09-14 18:45 UTC, Markus Wernig
Details
PDF/A signature OK hardtoken (35.60 KB, application/octect-stream)
2014-09-14 18:45 UTC, Markus Wernig
Details
valgrind trace LO 4.4.0.0 not crashing hardtoken (17.84 KB, text/plain)
2014-09-14 18:47 UTC, Markus Wernig
Details
output LO 4.4.0.0 crashing qualified hardtoken (5.33 KB, text/plain)
2014-09-14 18:49 UTC, Markus Wernig
Details
valgrind trace LO 4.4.0.0 not crashing qualified hardtoken signature NOK (18.70 KB, text/plain)
2014-09-14 18:50 UTC, Markus Wernig
Details
Untitled 1.pdf for the comment @ 02/12/2014 (25.75 KB, application/pdf)
2014-12-02 23:12 UTC, Tamas Domjan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tamas Domjan 2013-07-08 14:41:55 UTC
Created attachment 82188 [details]
Created by LibreOffice

Problem description: 
Background: Once 'experimental features' enabled under Tools / Options / LibreOffice / Advanced menu, become possible to export PDF with Digitally Signed. (Under Windows platform) LibO can use those Certificates which are installed to Windows / Internet explorer.
Issue: after export a document to PDF with using one of the installed certificate via File / Export to PDF /Digital signature tab, the opened PDF file in Acrobat reader contain a corrupted signature. (Same signatures can be used without any issue under PDFcreator software)
Tested on: 
- OS: Windows XP, 7, 8.1 RC
- LibreOffice 4.0.4.2 and 4.1 RC1
- Adobe Reader 10.1.7
- Tested Certificates: CAcer class1 and VeriSign class2
- PDF Creator 1.2.2

Steps to reproduce:
1. Install Digital Certificate under Windows /IE by double click onto your .p12 file and follow the  Certificate Import Wizard guidance.
2. Enable 'experimental features' under Tools / Options / LibreOffice / Advanced menu.
3. Export one of your document to PDF with Digital signature via File / Export to PDF /Digital signature tab. Choose one of your installed certificate and provide a password for that.
4. Open the created PDF file in Acrobat Reader.

Current behavior:
Malfunctioned signature reported by Adobe Reader:
Signature validity unknown. 
Error during signature verification.  
Error encountered while BER decoding.

Expected behavior:
Digital signature properly recognized from created PDF document. (Like it happen in case I use PDF creator as printer driver.)
              
Operating System: Windows XP
Version: 4.0.4.2 release
Comment 1 Tamas Domjan 2013-07-08 14:42:57 UTC
Created attachment 82189 [details]
Created by PDF Creator print driver from LibO
Comment 2 ign_christian 2014-07-02 14:03:15 UTC
Hi Tamas.. Does it solved in LO 4.2.5.2 or 4.3.0.1? 

If no please change status back to UNCONFIRMED, otherwise RESOLVED WORKSFORME
Comment 3 Tamas Domjan 2014-07-12 15:32:46 UTC
The problem become retested under Windows7 (64bit) environment with LibreOffice version 4.2.5.2. The situation is worst than it was before as LibreOffice crash when I try to export PDF with Digital signature. (PDF export without digital signature is working fine).

ps.: sorry for the late reply I was on vacation.
Comment 4 Tamas Domjan 2014-07-12 17:40:09 UTC
Addition to my previous comment: no PDF file created at the time of the LibreOffice 4.2.5.2 crash.


But I did an another test with LibreOffice version  4.3.0.2 (4.3 RC2), with this version the original behaviour returned, the LibO not crash, generate PDF, but the signature is corrupted in the PDF file with checking Acrobat Reader (ver 11.0.07) under Windows 7 SP1 64bit.
Comment 5 Markus Wernig 2014-09-09 10:38:35 UTC
Created attachment 105965 [details]
gdb output segfault
Comment 6 Markus Wernig 2014-09-09 10:39:26 UTC
Hi all

I am experiencing the crash behaviour in ALL versions that I try. I'll try to give a little more background, since kendy said that a proper bug report would be good:

platform: amd64
os: Gentoo Linux

1) LO 4.2.6.2, compiled with gcc-4.8.3
As described by the OP, LO just crashes. The exact point where it crashes is the same from the user's point of view: After clicking OK in the "Save File As" Dialog (the window title is "Export"). But when looking at the backtraces (generated after compiling glibc and LO with debug symbols "CFLAGS=-ggdb"), it appears to crash at different points in the code, roughly "somewhere in malloc.c".
Please see the four attached backtraces for the four crash types that I got with LO 4.2.6.2, when started with "gdb /usr/lib64/libreoffice/program/soffice.bin". The first one was still without debugging symbols in glibc.

2) LO 4.3.1.2, downloaded from prerelease server
Same behaviour, but up to now only the "double free or corruption (fasttop)" crash type occurred

platform: amd64
os: Ubuntu 14.04-LTS

3) 4.2.4-0ubuntu2
Similar behaviour, but I'll have to consolidate the output/backtrace, as it is some Ubuntu graphical tool displaying and formatting it. 


How to reproduce:
Prerequisites:
- First, obviously, the experimental features need to be turned on in "Tools->Options->Advanced".
- A digital signature certificate must be present in the NSS DB that LO is configured to use (Tools->Options->Security->Certificate Path). This can be a Firefox or Thunderbird store, or the certs can be imported with certutil.

1) Start LO Writer
2) Create new document (or open existing one)
3) Save document
4) Select "File->Export as PDF"
5) Click on Tab "Digital Signatures" in the Popup window
6) Click on "Select" under "Certificate"
7) Enter NSS DB password (if set) and select signature certificate, click OK
8) Click "Export". The "Export" Window (Save File As Dialog) opens.
9) Choose path and file name click "Save"
10) If the target pdf file name already exists, LO 4.2.6.2 asks if it should be overwritten and crashes after that question is answered. LO 4.3.1.2 does not ask, but crashes immediately.


I used the simplest of all writer documents (attached as "sigtest.odt").
Comment 7 Markus Wernig 2014-09-09 10:41:02 UTC
Created attachment 105966 [details]
gdb output 4.2.6.2 double free or
corruption (fasttop)

double free or corruption (fasttop)
Comment 8 Markus Wernig 2014-09-09 10:44:28 UTC
Created attachment 105967 [details]
gdb output 4.2.6.2 segfault
Comment 9 Markus Wernig 2014-09-09 10:45:17 UTC
Created attachment 105968 [details]
gdb output 4.2.6.2 corrupted double-linked list
Comment 10 Markus Wernig 2014-09-09 10:50:58 UTC
(In reply to comment #6)

> 10) If the target pdf file name already exists, LO 4.2.6.2 asks if it should
> be overwritten and crashes after that question is answered. LO 4.3.1.2 does
> not ask, but crashes immediately.

OK, sorry. The above is not true. Both versions ask, then crash.
Comment 11 Markus Wernig 2014-09-09 10:52:08 UTC
Created attachment 105970 [details]
test document
Comment 12 Markus Wernig 2014-09-09 10:59:35 UTC
Created attachment 105971 [details]
gdb output 4.3.1.2 double free or corruption (fasttop)
Comment 13 Markus Wernig 2014-09-12 10:43:26 UTC
As proposed by Michael, I've run the command through valgrind. Here's a summary:

1) LO 4.2.6.2, compiled with gcc-4.8.3, KDE-integration, debugging symbols in LO and glibc:
Does not run at all, aborts even before the splash screen is shown. (The program runs without issues when started without debugger or with gdb.)
See file valgrind-trace-4.2.6.2-with-dbg.txt

2) LO 4.3.1.2, downloaded from lo.org, no debugging symbols
In the first run, the program did not crash at all and produced a signed PDF!
See file valgrind-trace-4.3.1.2-nocrash-without-dbg.txt

In the second run, it crashed again.
See file valgrind-trace-4.3.1.2-crash-without-dbg.txt

I hope, the traces are still useful.
Comment 14 Markus Wernig 2014-09-12 10:44:24 UTC
Created attachment 106172 [details]
valgrind trace LO 4.2.6. 2 not starting
Comment 15 Markus Wernig 2014-09-12 10:45:01 UTC
Created attachment 106173 [details]
valgrind trace LO 4.3.1.2 not crashing
Comment 16 Markus Wernig 2014-09-12 10:45:29 UTC
Created attachment 106174 [details]
valgrind trace LO 4.3.1.2 crashing
Comment 17 Michael Meeks 2014-09-12 12:44:39 UTC
Thanks Markus - the --leak-check is not necessary and adds cruft at the end of the profile =) Using --error-limit=no would be more helpful I think.

The only thing I can see that may cause the grief is:

==26316== Invalid free() / delete / delete[] / realloc()
==26316==    at 0x4C29E7C: operator delete(void*) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26316==    by 0x9A153CE: vcl::PDFWriterImpl::finalizeSignature() (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libvcllo.so)
==26316==    by 0x9A44F75: vcl::PDFWriterImpl::emit() (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libvcllo.so)
==26316==    by 0x31DF867F: PDFExport::Export(rtl::OUString const&,
com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&)
(in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libpdffilterlo.so)
==26316==    by 0x31DFF2C6:
PDFFilter::implExport(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>
const&) (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libpdffilterlo.so)
==26316==    by 0x31E00522:
PDFFilter::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>
const&) (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libpdffilterlo.so)
==26316==    by 0x7B39DC9: SfxObjectShell::ExportTo(SfxMedium&) (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libsfxlo.so)
==26316==    by 0x7B3C74F: SfxObjectShell::SaveTo_Impl(SfxMedium&, SfxItemSet
const*) (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libsfxlo.so)
==26316==    by 0x7B3E690: SfxObjectShell::PreDoSaveAs_Impl(rtl::OUString
const&, rtl::OUString const&, SfxItemSet*) (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libsfxlo.so)
==26316==    by 0x7B3EFFA: SfxObjectShell::CommonSaveAs_Impl(INetURLObject
const&, rtl::OUString const&, SfxItemSet*) (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libsfxlo.so)
==26316==    by 0x7B28879: SfxObjectShell::APISaveAs_Impl(rtl::OUString
const&, SfxItemSet*) (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libsfxlo.so)
==26316==    by 0x7B78520: SfxBaseModel::impl_store(rtl::OUString const&,
com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&,
bool) (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libsfxlo.so)
==26316==  Address 0x1e6226b0 is 0 bytes inside a block of size 16 free'd
==26316==    at 0x4C299AC: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26316==    by 0xC330800: PR_Free (prmem.c:458)
==26316==    by 0x104A2DE0: PORT_Free_Util (secport.c:130)
==26316==    by 0xC594F17: HASH_Destroy (sechash.c:372)
==26316==    by 0x9A154C6: vcl::PDFWriterImpl::finalizeSignature() (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libvcllo.so)
==26316==    by 0x9A44F75: vcl::PDFWriterImpl::emit() (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libvcllo.so)
==26316==    by 0x31DF867F: PDFExport::Export(rtl::OUString const&,
com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&)
(in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libpdffilterlo.so)
==26316==    by 0x31DFF2C6:
PDFFilter::implExport(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>
const&) (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libpdffilterlo.so)
==26316==    by 0x31E00522:
PDFFilter::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>
const&) (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libpdffilterlo.so)
==26316==    by 0x7B39DC9: SfxObjectShell::ExportTo(SfxMedium&) (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libsfxlo.so)
==26316==    by 0x7B3C74F: SfxObjectShell::SaveTo_Impl(SfxMedium&, SfxItemSet
const*) (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libsfxlo.so)
==26316==    by 0x7B3E690: SfxObjectShell::PreDoSaveAs_Impl(rtl::OUString
const&, rtl::OUString const&, SfxItemSet*) (in
/home/markus/LibreOfficeDev/LibreOffice_4.3.1.2_Linux_x86-64_deb/installs/opt/libreoffice4.3/program/libsfxlo.so)
==26316==
Comment 18 Michael Meeks 2014-09-12 12:46:08 UTC
Unfortunately this trace -seems- to be of a build without debuginfo. Did you pass: --enable-symbols to autogen.sh ? that really helps get precise file / line-number information for your build.

Thanks !
Comment 19 Michael Meeks 2014-09-12 12:54:37 UTC
Looks like this:

    boost::scoped_ptr<HASHContext> hc(HASH_Create(HASH_AlgSHA1));

vs. the explicit destroy:

    HASH_End(hc.get(), digest.data, &digest.len, SHA1_LENGTH);
    HASH_Destroy(hc.get());

is the basic problem - a double free - ho hum; nice to use scoped_ptr of course - but not really with a C-style structure like this (I suspect).

Looks like it crept in here:

commit d73c039fa5353f0b96026bed4a0da31d9a41d2c7
Author: Markus Mohrhard <markus.mohrhard@googlemail.com>
Date:   Thu Sep 5 15:17:08 2013 +0200

    CID#1078782: fix memory leak
Comment 20 Commit Notification 2014-09-12 13:44:17 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea053226f641075ec4c1ccc214a9d5ab206afd08

fdo#66701 - don't double destroy the HASH when PDF signing.



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.
Comment 21 Michael Meeks 2014-09-12 14:13:30 UTC
Markus - that should fix it; if you can build yourself, I'd just build master & play - unfortunately, I don't have my digital signature foo setup - so I can't even test it; but - reading the code & valgrind log we avoid one major problem at least =) feedback appreciated.
Comment 22 Markus Wernig 2014-09-13 21:29:30 UTC
Michael

I git cloned git://anongit.freedesktop.org/libreoffice/core today to  commit 6ceff3f7deb1a6b66c0119c73b797a925f8fbee7 and built with gcc-4.8.3 and ./autogen.sh --enable-symbols --without-krb5 --without-gssapi --without-junit --with-jdk-home=/etc/java-config-2/current-system-vm.

The resulting binary does indeed no longer crash. Good work!

I'll be looking at the resulting signed PDF files shortly and report.

Kind regards
/markus
Comment 23 Tamas Domjan 2014-09-14 15:58:40 UTC
Hi Michael & Markus,

Thank you very much for working on a solution for this issue.
Would you be able to provide a link to a (Win) compiled version of the patched release? Then I would be able to test the signed PDF creation with my certificate.
Comment 24 Markus Wernig 2014-09-14 16:20:45 UTC
Hi Tamas

I think you should find what you need here: http://dev-builds.libreoffice.org/daily/master/

Please report back any findings. Also what kind of certificate you are using (softtoken or hardtoken)
Comment 25 Markus Wernig 2014-09-14 18:42:50 UTC
Michael

I have now run a couple of tests, trying to create signed PDFs with three
different certificates:

- Soft certificate ("softtoken"). This was a plain PKCS#12 file imported into
  the Mozilla NSS DB store.
- Advanced certificate ("hardtoken"). This was a plain PKCS#7 certificate on
  an RSA token with associated private key on the token. Key usage was
authentication/signing (i.e. no encryption).
- Qualified certificate ("qualified hardtoken"). This was a PKCS#7 certificate
  stored in the SigG partition of the same RSA key, together with its private
key. 
Both "hardtoken" certificates were visible through the NSS DB, where the token
had been added and the appropriate PKCS#11 library configured (libCVP11 and
libCVP11LCB respectively). This library is used by the NSS DB to communicate
with the RSA token and handles all token commands, prompting for PINs through
own helper programs if necessary, etc. The token works in both Thunderbird and
Mozilla.

The Acrobat version I used was Adobe Reader 9, Version 9.5.5 04/26/2013 on
Linux amd64. It would of course be necessary to verify the attached PDFs in a
newer version on other OSes (Tamas, could you do that on Win, maybe?).

The results already look better than we thought in the beginning, but there
are some errors that might be hard to track down.


Here's what I've found (The build was still 4.4.0.0-alpha0 with debug symbols)

1) Softtoken: The signature operation creates a signed PDF. It remains unclear
though, what the purpose of the "Certificate Password" field in the
certificate selection page is. Since the NSS DB store is already unlocked in a
separate dialog, I don't see any purpose in entering an additional (which??)
password, and leaving it empty made no difference.

The signature can be validated by Adobe Acrobat and any other tool that I got
my hands on! The only point was that Adobe has to have the root CA of the
signing certificate imported and trusted. 

So the PDF signature seems to work per se, but the dialog could be improved to
make the options clearer (a help page would also be very useful!)

I created both signed PDF and PDF/A. See files sigtest.pdf and sigtest-a.pdf.

2) Hardtoken: After inserting the token, I first ran the program normally
(i.e. without gdb or valgrind). 
The NSS dialog now correctly asked for two token passwords (one for the
internal NSS DB store and one for the token), then all certificates (from
softstore and token) showed up in the list. I selected the "normal"
authentication certificate from the hardtoken, and the signature was made
successfully. It also could be validated in Adobe! See file
sigtest-a-adv-sig.pdf.
Then i tried to repeat the procedure, and got this error on the console (where
I had started soffice.bin), when I clicked the "Select" button on the "Digital
Signatures" tab:

(process:26412): GLib-CRITICAL **: g_slice_set_config: assertion
'sys_page_size == 0' failed

The program then stopped responding and froze. It had to be killed.
I tried to reproduce this under valgrind, but unfortunately, it didn't freeze
under valgrind. I've attached the trace nevertheless:
valgrind-trace-4.4.0.0-nocrash-ok-advanced-sig-hardwaretoken-with-dbg.txt

3) Qualified hardtoken: First, without gdb/valgrind. Everything was the same
as above, with the libCVP11 correctly launching an external program
(/usr/local/bin/swisssign-pin-entry via /bin/sh) in order to request the
signature PIN of the SigG partition. After selecting the file to write, the
program crashed again with the output captured in
output-4.4.0.0-crash-qual-sig.txt.

Then the same under valgrind: As before, the program didn't crash and produced
a PDF. But the signature PIN was never asked for (most likely a valgrind
artefact), and the resulting PDF shows to be signed, some non-cryptographic
attributes of the signature (date, comment) are present. But the signature
itself is completely broken and cannot be validated in any program.

Actually, it even crashes most of the programs I've tried to validate it with.
One produced a Java stacktrace, from which I'd guessed that the signature was
not even a valid structure:

java.lang.IllegalArgumentException: can't decode PKCS7SignedData object   at
com.itextpdf.text.pdf.PdfPKCS7. (PdfPKCS7.java:434)

Which makes sense, since the signature PIN was not requested (seems the helper
program segfaulted under valgrind). 
Actually, the resulting signature is all zeroes (see lines 285ff. of
sigtest-a-qual-sig.pdf). 

Looking at the Signature Properties -> Verification error in Adobe Acrobat, I
get the same (totally inconclusive) message as Tamas did in his original post:

Error during signature verification.  
Error encountered while BER decoding:

The output from that is in
valgrind-trace-4.4.0.0-nocrash-broken-qualified-sig-hardwaretoken-with-dbg.txt


So we seem to have different conditions under which LO still crashes when
trying to sign the PDF. 
Currently, I believe that the broken "qualified hardtoken" signature is only
due to the fact that the external helper program has aborted. In that case, LO
should really not try to create the document at all, as the signature
operation through NSS must surely have failed.
Comment 26 Markus Wernig 2014-09-14 18:44:43 UTC
Created attachment 106281 [details]
PDF signature OK
Comment 27 Markus Wernig 2014-09-14 18:45:16 UTC
Created attachment 106282 [details]
PDF/A signature OK
Comment 28 Markus Wernig 2014-09-14 18:45:45 UTC
Created attachment 106283 [details]
PDF/A signature OK hardtoken
Comment 29 Markus Wernig 2014-09-14 18:47:29 UTC
Created attachment 106284 [details]
valgrind trace LO 4.4.0.0 not crashing hardtoken
Comment 30 Markus Wernig 2014-09-14 18:49:01 UTC
Created attachment 106286 [details]
output LO 4.4.0.0 crashing qualified hardtoken
Comment 31 Markus Wernig 2014-09-14 18:50:26 UTC
Created attachment 106287 [details]
valgrind trace LO 4.4.0.0 not crashing qualified hardtoken signature NOK
Comment 32 Markus Wernig 2014-09-14 19:15:31 UTC
BTW. when signing the document itself using File->Digital Signatures, all works well with softtoken and all hardtokens. We can even apply a qualified signature to the ODT (which is very cool, btw.)
Comment 33 Markus Wernig 2014-09-14 19:39:07 UTC
I had a look at Tamas' original document here: https://bugs.freedesktop.org/attachment.cgi?id=82188. 

As in my case, there was no signature at all, but only a blob of zeroes where the signature should be. It seems that in his case some similar error occurred when NSS tried to use the private key for signing. Apparently, there is an error condition that is not handled in LO.
Comment 34 Michael Meeks 2014-09-15 19:52:17 UTC
Hi Markus,

This bug is getting extremely unwield. Can we close it, and create a series of new individual bugs, and also a tracker bug that aggregates them all via the "Depends on:" field (just add comma separated bug numbers there).

Wrt. the valgrind traces; it'd be really good to have symbols for:

/usr/local/lib/libcvP11.so

no idea what package that comes from; or is it self-built ?

 Invalid read of size 1
==12223==    at 0x295B381C: ??? (in /usr/local/lib/libcvP11.so)
==12223==    by 0x2943A862: ??? (in /usr/local/lib/libcvP11.so)

It's also good to use --num-callers=60 or so with LibreOffice -since we have some rather deep stacks to unwind =) It'd be great to have this new crash filed as a separate bug - please do CC me on that (and the new tracker).

Thanks ! =)
Comment 35 Markus Wernig 2014-09-16 17:18:18 UTC
Ok, created bug 83940 as tracker and split problem in two new bugs (bug 83937, bug 83939).

Hope that's OK for everyone.

I would still like to know the results of Tamas' tests with the dev build, if possible.

As for libcvP11, it's a vendor provided library that comes with the RSA token. I've asked them if they can send me a version with debugging symbols.
Comment 36 V Stuart Foote 2014-10-25 17:05:46 UTC
A little QA housekeeping, setting resolved fixed and also target:4.3.3 for
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-3-3&id=0442fd0936be714284feb8d36d3389a7ffcb87c8

See tracking bug 83940 -- PDF signatures (tracker), and remaining issues as split off of issues bug 83937 -- LibreOffice crashes when creating digitally signed PDF and bug 83939 -- LibreOffice creates invalid signature when creating digitally signed PDF
Comment 37 Tor Lillqvist 2014-12-02 13:10:29 UTC
By the way, Adobe Reader XI (11.0.09) says that also the allegedly correct digital_signature_correct.pdf document attached in Comment #1 has problems:

Signature validity is unknown:
  Document has not been modified since this signature was applied
  Signer's identity is unknown because it has not been ...
  Signing time is from the clock on the signer's computer

I am now comparing with a sample signed PDF from Adobe itself instead: http://blogs.adobe.com/security/SampleSignedPDFDocument.pdf
Comment 38 Markus Wernig 2014-12-02 13:32:41 UTC
Can you give the entire error message?

It looks like Acrobat can read the signature, but has a problem with it.
Make sure that the CA that has issued the signing certificate is imported in Acrobat's trust store.
Comment 39 Tamas Domjan 2014-12-02 14:09:10 UTC
(In reply to Tor Lillqvist from comment #37)
> By the way, Adobe Reader XI (11.0.09) says that also the allegedly correct
> digital_signature_correct.pdf document attached in Comment #1 has problems:
> 
> Signature validity is unknown:
>   Document has not been modified since this signature was applied
>   Signer's identity is unknown because it has not been ...
>   Signing time is from the clock on the signer's computer
> 
> I am now comparing with a sample signed PDF from Adobe itself instead:
> http://blogs.adobe.com/security/SampleSignedPDFDocument.pdf

The Comment 1 contain a correctly signed sample PDF which was NOT created with LibreOffice. That was created with PDF Creator print driver product (www.pdfforge.org/pdfcreator).
Comment 40 Tor Lillqvist 2014-12-02 14:14:47 UTC
Well, it can be a matter of taste what is "correctly signed" and what is not. Presumably many "normal" users use the latest version of Adobe Reader, and it claims the signature is invalid. (Even if nothing else is invalid, the certificate used for signing is both expired (expired 2013-12-27) and not trusted.)
Comment 41 Tor Lillqvist 2014-12-02 14:19:28 UTC
(But sure, the certificate was not expired at the time of signing, so by default, if I understand correctly, Adobe Reader should not mind that it is expired now.)
Comment 42 Tamas Domjan 2014-12-02 14:52:41 UTC
(In reply to Tor Lillqvist from comment #41)
> (But sure, the certificate was not expired at the time of signing, so by
> default, if I understand correctly, Adobe Reader should not mind that it is
> expired now.)

But it not change on that fact the LibreOffice produce invalid Digitally Signed PDFs, and 3rp party tools are required for Sign PFS if require (like PDF Creator).
So I hope the developers of LibO will find and correct the bug which cause this issue soon.
Comment 43 Markus Wernig 2014-12-02 15:18:17 UTC
(In reply to Tor Lillqvist from comment #41)
> (But sure, the certificate was not expired at the time of signing, so by
> default, if I understand correctly, Adobe Reader should not mind that it is
> expired now.)

That is only true if the signature was made with long-term validation (LTV), which in turn is even more complicated (an additional step beside including the timestamp is including an OCSP repsonse for the signing certificate from the moment of the signature, showing that it was valid at the time the signature was made - only then does Acrobat show the signature as valid even after the signing certificate has expired)
Comment 44 Markus Wernig 2014-12-02 15:30:51 UTC
(In reply to Tor Lillqvist from comment #40)
> Well, it can be a matter of taste what is "correctly signed" and what is
> not. Presumably many "normal" users use the latest version of Adobe Reader,
> and it claims the signature is invalid. (Even if nothing else is invalid,
> the certificate used for signing is both expired (expired 2013-12-27) and
> not trusted.)

For the purpose of this bug, the test document in Comment1 is correctly signed:

- Contains a cryptographically consistant signature
- Contains a certificate and chain that match the signature
- Contains a date

As I've pointed out in Comment33, the original document submitted by Tamas contains none of the above but only a large blob of zeroes where the signature should be.
Comment 45 Tor Lillqvist 2014-12-02 16:54:24 UTC
Yes, I have now noticed the long string of zeroes (that is supposed to get overwritten by the actual signature). Debugging it.
Comment 46 Markus Wernig 2014-12-02 22:26:26 UTC
(In reply to Tor Lillqvist from comment #45)
> Yes, I have now noticed the long string of zeroes (that is supposed to get
> overwritten by the actual signature). Debugging it.

Tor. The document submitted by Tamas was created with a LO version from at least 1.5 years ago. It might not be useful to debug that.

I have asked Tamas in Comment24 to repeat his test with a current version, but without any reply so far.

@Tamas: Did you get a chance to repeat your test with a current build?
Comment 47 Tamas Domjan 2014-12-02 23:12:07 UTC
Created attachment 110377 [details]
Untitled 1.pdf for the comment @ 02/12/2014
Comment 48 Tamas Domjan 2014-12-02 23:12:27 UTC
Hello Markus,

Sorry, I totally forgot that I not provided feedback before. Now I downloaded the 4.5.0.0.alpha0 and run on Windwos 7 x86 with Acrobat Reader 11.0.09. I also used a recent version of digital certificate which will expire only on 11 April 2015. I enabled the experimental functions in the LibO then I created a signed PDF export.
LibreOffice not crashed and a PDF file created, once I open the file in the Acrobat Reader the content is OK, but the digital signature is still corrupt. I attach the PDF output in a name "Untitled 1.pdf".
Comment 49 Markus Wernig 2014-12-03 01:01:31 UTC
(In reply to Tamas Domjan from comment #48)
> Hello Markus,
> 
> Sorry, I totally forgot that I not provided feedback before. Now I
> downloaded the 4.5.0.0.alpha0 and run on Windwos 7 x86 with Acrobat Reader
> 11.0.09. I also used a recent version of digital certificate which will
> expire only on 11 April 2015. I enabled the experimental functions in the
> LibO then I created a signed PDF export.
> LibreOffice not crashed and a PDF file created, once I open the file in the
> Acrobat Reader the content is OK, but the digital signature is still
> corrupt. I attach the PDF output in a name "Untitled 1.pdf".

Hi Tamas

Thanks for the feedback

This problem seems to be platform dependent. On Linux, the same operation succeeds.

Tamas, just to rule out any obvious error sources, could you please detail:

- which certificate store you were using (NSS, Windows store, ...)
- if the signature was calculated on any hardware token (via pkcs#11 library), or entirely in software
- if you are able to sign the same document (not the PDF output) with the same method (store and certificate) in the ODF version (File -> Digital Signatures -> (Select Certificate via certificate store)
?

Thx /markus
Comment 50 Tor Lillqvist 2014-12-03 10:21:18 UTC
Re: Comment #46, I am not debugging the old attached document, but the code.
Comment 51 Markus Wernig 2014-12-05 12:40:58 UTC
Followed-up in https://bugs.freedesktop.org/show_bug.cgi?id=87030