PDF signing feature backported from 4.4

fdo#83939: Check return value from pPDFWriter->Emit()

Change-Id: Id492b1b6b9d534276c155b1e46953d098ce8b969

fdo#83939: Add new error code for failed PDF signing, and handle it

Conflicts:
	filter/source/pdf/impdialog.hrc
	filter/source/pdf/impdialog.src

Change-Id: Ide6dc06d33faea795272d9d32fc028ac8d023c5a

fdo#83939: Set error code if signing failed

Change-Id: I45f1077c744e20a369a73bf0b83c8dba04ddcda7

Use the "vcl.pdfwriter" logging tag instead of "vcl.gdi"

Change-Id: If53448ccfd0c156d4971ba994173b2d92af50138

We want PDF signing to be non-experimental now

Change-Id: Ic02d1f5169197edd8f9793befd45adf5db145a3b

Bin noise comments

Change-Id: I084040ff90ee30aa83ac5d3ad11365768272ec65

Bin noise comments and superfluous blank lines

Change-Id: Idec496b778d708fb6fa4c004329f8e734276052a

Remove noise SAL_WARNs that were not warnings, just informative messages

SAL_DEBUG is what should be used for stuff like that (and not committed).

Change-Id: I08505418bf9b55082e0d7672b85f3f76262dbad0

fdo#87030: PDF signing using Windows API, work in progress

Started writing a Windows version of PDFWriterImpl::finalizeSignature(). The
certificate we get from the selection dialog (in xmlsecurity) is from the
Windows built-in store anyway, so it is pointless to try to use it with
NSS. (See bug for longer discussion.)

So far it was pretty straightforward. The WinCrypt API seems clean and easy to
use. But for some reason the CryptSignHash() call fails with "Keyset does not
exist" (NTE_BAD_KEYSET). What am I missing?

Anyway, comitting this now as it does compile and doesn't make things worse.

Change-Id: I0941995ad6e22c5487c6e6fe0084d3df0b2341c7

fdo#87030: Prevent PDF signing using Windows API from failing

There was one details that I had missed in my initial coding:
CryptAcquireContext() doesn't give you a HCRYPTPROV key container that
would contain the private key of a public key certificate. For that
you need to use CryptAcquireCertificatePrivateKey(). When the hash has
been created using such a HCRYPTPROV, the CryptSignHash() call
succeeds.

The certificate in DER encoding that is passed in from the caller,
obtained in the certificate chooser (in xmlsecurity), is possibly not
good enough to be used for the other things. So look the same (?)
certificate up in the user's key store instead. At least more
properties are present in the certificate when looked up like that.

Add more SAL_INFO logging, with cleartext dumping of certificate
context property names and list of algorithms supported by the CSP.

Unfortunately, even if all the WinCrypt API calls now succeed, the
signatures we produce still are not good enough for Adobe Reader... A
lot of information must be missing, they are quite short, just 256
bytes.

Change-Id: Ifa4dd37b6d40932fcdcbb07e00c9eb52d54a5477

fdo#87030: Generate a proper PKCS#7 signature

The signature should be in DER-encoded PKCS#7 format and what CryptSignHash()
produces is nothing like that. Luckily CryptSignMessage() is actually almost
easier to use and is capable of doing what we need. This also means that we
won't need any HCRYPTPROV or HCRYPTHASH after all so all the code related to
that can be removed. CryptSignMessage() handles both calculating the hash and
signing it.

One less than ideal issue with CryptSignMessage() is that it needs all the
data to be hashed and signed at the same time, so we need to keep both buffers
around for signing.

It also turns out that we don't need to look up the certificate anew from the
user's certificate store after all.

Now Adobe Reader doesn't complain any longer about the signature's format and
contents.

Change-Id: I25cfb93b516ffa723c6228d068d9ffa8e7cc4790
fdo#37814: SHCreateItemFromParsingName doesn't like LO's file URLs

...but apparently wants pathnames instead, cf. the other use of it in
WinSalInstance::AddToRecentDocumentList (vcl/win/source/app/salinst.cxx).

Change-Id: Iaa64ff82915f7cbfee55b4389387b226f7adc919
(cherry picked from commit e123ffd66088783ce74a7b5f15e9d324b39ecf67)