Created attachment 82189 [details]
Created by PDF Creator print driver from LibO

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

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.

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.

Created attachment 105965 [details]
gdb output segfault

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").

Created attachment 105966 [details]
gdb output 4.2.6.2 double free or
corruption (fasttop)

double free or corruption (fasttop)

Created attachment 105967 [details]
gdb output 4.2.6.2 segfault

Created attachment 105968 [details]
gdb output 4.2.6.2 corrupted double-linked list

(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.

Created attachment 105970 [details]
test document

Created attachment 105971 [details]
gdb output 4.3.1.2 double free or corruption (fasttop)

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.

Created attachment 106172 [details]
valgrind trace LO 4.2.6. 2 not starting

Created attachment 106173 [details]
valgrind trace LO 4.3.1.2 not crashing

Created attachment 106174 [details]
valgrind trace LO 4.3.1.2 crashing

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==

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 !

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

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.

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.

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

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.

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)

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.

Created attachment 106281 [details]
PDF signature OK

Created attachment 106282 [details]
PDF/A signature OK

Created attachment 106283 [details]
PDF/A signature OK hardtoken

Created attachment 106284 [details]
valgrind trace LO 4.4.0.0 not crashing hardtoken

Created attachment 106286 [details]
output LO 4.4.0.0 crashing qualified hardtoken

Created attachment 106287 [details]
valgrind trace LO 4.4.0.0 not crashing qualified hardtoken signature NOK

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.)

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.

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 ! =)

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.

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

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

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.

(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).

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.)

(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.)

(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.

(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)

(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.

Yes, I have now noticed the long string of zeroes (that is supposed to get overwritten by the actual signature). Debugging it.

(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?

Created attachment 110377 [details]
Untitled 1.pdf for the comment @ 02/12/2014

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".

(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

Re: Comment #46, I am not debugging the old attached document, but the code.

Followed-up in https://bugs.freedesktop.org/show_bug.cgi?id=87030