summaryrefslogtreecommitdiff
path: root/xmlsecurity/source/pdfio/pdfdocument.cxx
AgeCommit message (Collapse)AuthorFilesLines
2021-11-24Add missing GetSubjectName for Windows buildmimo-5.4.7.2.M9Tomaž Vajngerl1-0/+46
Change-Id: Ibffc5edd3c0937994c405f82ba8656c24c154342
2021-11-23xmlsecurity: improve handling of multiple X509Data elementsMichael Stahl1-2/+12
Combine everything related to a certificate in a new struct X509Data. The CertDigest is not actually written in the X509Data element but in xades:Cert, so try to find the matching entry in XSecController::setX509CertDigest(). There was a confusing interaction with PGP signatures, where ouGpgKeyID was used for import, but export wrote the value from ouCertDigest instead - this needed fixing. The main point of this is enforcing a constraint from xmldsig-core 4.5.4: All certificates appearing in an X509Data element MUST relate to the validation key by either containing it or being part of a certification chain that terminates in a certificate containing the validation key. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111254 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 9e82509b09f5fe2eb77bcdb8fd193c71923abb67) xmlsecurity: improve handling of multiple certificates per X509Data It turns out that an X509Data element can contain an arbitrary number of each of its child elements. How exactly certificates of an issuer chain may or should be distributed across multiple X509Data elements isn't terribly obvious. One thing that is clear is that any element that refers to or contains one particular certificate has to be a child of the same X509Data element, although in no particular order, so try to match the 2 such elements that the parser supports in XSecController::setX509Data(). Presumably the only way it makes sense to have multiple signing certificates is if they all contain the same key but are signed by different CAs. This case isn't handled currently; CheckX509Data() will complain there's not a single chain and validation of the certificates will fail. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111500 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 5af5ea893bcb8a8eb472ac11133da10e5a604e66) xmlsecurity: add EqualDistinguishedNames() Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111545 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 1d3da3486d827dd5e7a3bf1c7a533f5aa9860e42) xmlsecurity: avoid exception in DigitalSignaturesDialog::getCertificate() Fallback to PGP if there's no X509 signing certificate because CheckX509Data() failed prevents the dialog from popping up. To avoid confusing the user in this situation, the dialog should show no certificate, which is already the case. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111664 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 90b725675c2964f4a151d802d9afedd8bc2ae1a7) xmlsecurity: fix crash in DocumentDigitalSignatures::isAuthorTrusted() If the argument is null. This function also should use EqualDistinguishedNames(). Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111667 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit ca98e505cd69bf95d8ddb9387cf3f8e03ae4577d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111910 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit a1cf770c2d7ca3e153e0b1f01ddcc313bc2bed7f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113058 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 8558bc8a0702bf41e020018f469b9feccd99f92d) Conflicts: include/svl/sigstruct.hxx xmlsecurity/inc/xmlsignaturehelper.hxx xmlsecurity/source/helper/pdfsignaturehelper.cxx xmlsecurity/source/helper/xsecparser.cxx xmlsecurity/source/helper/xsecsign.cxx xmlsecurity/source/xmlsec/mscrypt/x509certificate_mscryptimpl.cxx xmlsecurity/source/xmlsec/nss/x509certificate_nssimpl.cxx xmlsecurity/source/xmlsec/nss/xmlsignature_nssimpl.cxx (cherry picked from commit ed914263f07acabcea8681418d9d277d62e22ed5) Conflicts: include/svl/sigstruct.hxx svl/source/crypto/cryptosign.cxx sw/source/core/edit/edfcol.cxx xmlsecurity/inc/xsecctl.hxx xmlsecurity/source/component/documentdigitalsignatures.cxx xmlsecurity/source/dialogs/digitalsignaturesdialog.cxx xmlsecurity/source/helper/xmlsignaturehelper.cxx xmlsecurity/source/helper/xsecctl.cxx xmlsecurity/source/helper/xsecverify.cxx xmlsecurity/source/xmlsec/mscrypt/x509certificate_mscryptimpl.cxx xmlsecurity/source/xmlsec/nss/x509certificate_nssimpl.cxx Change-Id: I9633a980b0c18d58dfce24fc59396a833498a77d
2017-03-22Use rtl::isAscii* instead of ctype.h is* (and fix passing plain char)Stephan Bergmann1-1/+2
Change-Id: I0b478dfa25a54595ba0dcee1ca3ec0291ee94ef5
2017-03-22vcl: move in PDF tokenizer from xmlsecurityMiklos Vajna1-2934/+44
The PDF code in xmlsecurity served two purposes: - a generic PDF tokenizer - signature verification The first purpose is useful to have in VCL, so the PDF export code can use it as well when it comes to PDF image handling. This commit just moves most of the PDF code to VCL, it does not touch the PDF export code yet. With this, also the somewhat odd xmlsecurity dependency of CppunitTest_vcl_pdfexport can be removed as well. Change-Id: I6fe8294ed5c4aa4d79f4b2ddef80a4d1c9d566cc Reviewed-on: https://gerrit.libreoffice.org/35513 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-03-21xmlsecurity: separate signature verification from PDF tokenizerMiklos Vajna1-1/+1
Signature verification code depends on sax and xmloff, but the rest of the PDF tokenizer could be otherwise moved down to lower layers without problems. Change-Id: Ieca57279e9517935821c1d34f217fd10548035ef Reviewed-on: https://gerrit.libreoffice.org/35512 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-03-21Make PDFDocument::ReadKeyword work at end of fileStephan Bergmann1-1/+3
If the first ReadChar fails due to EOF, ch would be used uninitialized. If the second ReadChar fails due to EOF, the SeekRel(-1) shouldn't be executed. Change-Id: Ibf99539a3a8880a77653bd7576721104f9782e36 Reviewed-on: https://gerrit.libreoffice.org/35504 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-03-16xmlsecurity: use auto when declaring iteratorsMiklos Vajna1-2/+2
Change-Id: Ie56c0c0e1917f159957babca346f1a3fa04bc629 Reviewed-on: https://gerrit.libreoffice.org/35253 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-02-27tdf#105093 vcl PDF export: add embedded video testcaseMiklos Vajna1-31/+5
Fails with commit 4ad249af88d15f2c8a09f0721a59d82718fcc201 (tdf#105093 sd PDF export: handle embedded videos, 2017-01-04) reverted. Change-Id: I413ec9a5da3c0783541dcd28fb9a62dd896f955b Reviewed-on: https://gerrit.libreoffice.org/34681 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-02-27xmlsecurity PDF verify: fix parsing of nested dictionariesMiklos Vajna1-2/+2
This is triggered by an upcoming unit test for tdf#105093. Change-Id: I3c8e8662fcadaea1f6e19bf6194d8159916f368b Reviewed-on: https://gerrit.libreoffice.org/34678 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-02-27tdf#105461 vcl: add text highlight textcaseMiklos Vajna1-13/+13
Fails with commit ee32c7d8083ae1449d6b379034be92995c142da9 (tdf#105461 PDF export: handle text fill color, 2017-02-01) reverted. Change-Id: I3628a16d0810e3be3fb352340d06cdba472dcd3f Reviewed-on: https://gerrit.libreoffice.org/34621 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-02-24vcl: add initial CppunitTest_vcl_pdfexportMiklos Vajna1-26/+15
Invoke the PDF export filter and then use the PDF tokenizer from xmlsecurity to assert the contents of created PDF file. The testcase fails with commit 6db0f1feb1d9931d2726dd11a889c58815710ce0 (tdf#106059 PDF export: create a reference XObject for PDF images, 2017-02-22) reverted. Change-Id: I90526fef41d9560ae447f586df766bc50a491c43 Reviewed-on: https://gerrit.libreoffice.org/34609 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-02-24xmlsecurity PDF verify: handle multiple startxref in the last 1024 bytesMiklos Vajna1-3/+16
Usually this is not a problem, but it's easy to construct a document manually that contains multiple startxref tokens at the last 1024 bytes. Make sure we read the last of those, not the first one. This is triggered by an upcoming unit test for tdf#106059. Change-Id: I94fbb5d407c4a03b7c2c6e207200127bb374e750 Reviewed-on: https://gerrit.libreoffice.org/34607 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-02-21loplugin:subtlezeroinit: xmlsecurityStephan Bergmann1-5/+5
Change-Id: Ife06c74e1665273350b497a1a584d7f76297c13d
2017-02-01xmlsecurity: various small cleanupsMiklos Vajna1-37/+30
Change-Id: Id713460036331fd9f98fd1eca85ca61f57cf5afe Reviewed-on: https://gerrit.libreoffice.org/33779 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-12-02xmlsecurity mscrypto PDF verify: implement support for non-detached signaturesMiklos Vajna1-8/+104
This was the last unit test that was disabled on Windows due to missing implementation. Change-Id: Ia7d84f72bcdf79267c7de17cd8822ed02c378642 Reviewed-on: https://gerrit.libreoffice.org/31552 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-12-01xmlsecurity PDF verify: avoid seeking before the start of the streamMiklos Vajna1-1/+5
Happened when the doc was smaller than 1024 bytes. Change-Id: Ie5eea5905a09722e7958495d26e6c78ee234d3ba Reviewed-on: https://gerrit.libreoffice.org/31500 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-12-01xmlsecurity PDF verify: handle no EOL at EOFMiklos Vajna1-3/+39
From a comment's point of view, EOF is just a terminator, similar to \r or \n. Change-Id: I120bf1e75f1eb81a550af643051e6fc472873eff Reviewed-on: https://gerrit.libreoffice.org/31499 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-12-01xmlsecurity PDF verify: fix reading names containing ']'Miklos Vajna1-7/+12
Also fix parsing '<< /Foo [ /Bar ] >>'. Change-Id: I3375001730b4d2e447b0dd8a7809a7bfb013126c Reviewed-on: https://gerrit.libreoffice.org/31498 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-12-01xmlsecurity PDF verify: don't abort read on partial signMiklos Vajna1-4/+2
Map it to the partially signed (not all streams) ODF concept instead. Change-Id: I7fc931e622b9f10a1261cd475b01a2f038e37ece Reviewed-on: https://gerrit.libreoffice.org/31497 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-12-01xmlsecurity PDF verify: handle boolean type as dictionary valueMiklos Vajna1-1/+11
This caused not finding the length of a stream -> could not actually verify signature. Change-Id: I696b6da49525eb53f7575c27f619d2116be51f1d Reviewed-on: https://gerrit.libreoffice.org/31490 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-12-01xmlsecurity PDF verify: CR is also a terminator of a commentMiklos Vajna1-1/+1
If we skip to the first NL, then we start tokenizing some XML as PDF data and soon error out due to an unexpected keyword. Change-Id: I86b540a014e5a92ea4376ed765385a2ee568a3c1 Reviewed-on: https://gerrit.libreoffice.org/31472 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-12-01xmlsecurity PDF verify: tolerate missing %%EOF in incremental updatesMiklos Vajna1-4/+8
This is broken, but work it around to avoid an infinite loop. Change-Id: I132a3c19cfe53e6166bfc1a881d1bfa5071f85d4 Reviewed-on: https://gerrit.libreoffice.org/31471 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-12-01xmlsecurity PDF verify: support non-detached signaturesMiklos Vajna1-11/+15
And a couple of other changes to accept the bugdoc from <https://github.com/esig/dss/ dss-pades/target/test-classes/plugtest/esig2014/ESIG-PAdES/RO/Signature-P-RO-4.pdf>. Change-Id: I0fca9ba0bfe927ef91ae2592a5026b05d19879fd Reviewed-on: https://gerrit.libreoffice.org/31462 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-11-30xmlsecurity PDF verify: look for the signingCertificateV2 attributeMiklos Vajna1-0/+205
This is a required part of the PAdES spec, but so far we only wrote it. As a start just expose if the attribute exists or not. Change-Id: Iae3815f764973a2fd29d72593236c2f484172101 Reviewed-on: https://gerrit.libreoffice.org/31436 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-11-28CppunitTest_xmlsecurity_signing: fix this on Windows with non-empty cert storeMiklos Vajna1-0/+22
The NSS code earlier started to save the hash algo ID of the signature into the signature structure and I also added a unit test for this. This failed on Windows when the system had at least one signing certificate installed, as the mscrypto part of the patch was missing. Change-Id: Ib09e9e53292b5beb011c96ecf6f51a5ee10c15b0 Reviewed-on: https://gerrit.libreoffice.org/31323 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-11-25CppunitTest_xmlsecurity_pdfsigning: add PAdES testcaseMiklos Vajna1-65/+5
Assert the two user-visible changes: SHA-256 hashes and the SubFilter of the signature. Change-Id: I12a2355e2ddfc368bed4430a7b5ad244b5778afe Reviewed-on: https://gerrit.libreoffice.org/31173 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-11-24xmlsecurity mscrypto PDF sign: conditionally add back CAdES SubFilterMiklos Vajna1-4/+0
We can now write that on Windows as well when requested, after the signing-certificate attribute is implemented using mscrypto. With this, the PAdES validator at <http://signatures-conformance-checker.etsi.org/protected/upload.php?sigtype=padesconf> finds our Windows signature valid. Change-Id: Iaeb4c36a1eac14e3d3c3c12d9cfd9529e7663f77 Reviewed-on: https://gerrit.libreoffice.org/31162 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-11-23vcl mscrypto PDF sign: add initial 'signing-certificate' signed attributeMiklos Vajna1-1/+1
Equivalent of the earlier NSS commit, payload is just an empty sequence at the moment. Change-Id: I4639e2514ef01d23da04aedc30f63f9e8878223b Reviewed-on: https://gerrit.libreoffice.org/31108 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-11-22vcl PDF mscrypto sign: upgrade SHA-1 hash to SHA-256Miklos Vajna1-0/+10
Also: - avoid writing ETSI.CAdES.detached for now on Windows till doing so results in an invalid signature in Acrobat - extend the SEC_OID_PKCS1_SHA1_WITH_RSA_ENCRYPTION hack to do the same for SHA256 and SHA512 as well, as Acrobat and NSS accepts such signatures Change-Id: Ibb0a204504b29230dd712ffb709d2037c1007218
2016-11-17xmlsecurity PDF sign: handle AdES when writing SubFilterMiklos Vajna1-5/+9
Page 21 of "PAdES baseline signatures" specification from <http://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.01.01_60/en_31914201v010101p.pdf> says: "The Signature Dictionary shall contain a value of ETSI.CAdES.detached for the key SubFilter." So in case the UI has the adescompliant checkbox enabled, write that value instead of the Adobe default. Change-Id: I69e606a32fb09bebd5e9b25b32150d1b8672f544
2016-11-11xmlsecurity: extract parts of PDFDocument::Sign() into separate functionsMiklos Vajna1-33/+84
Hopefully it's easier to read this way. Change-Id: I145e00f8e57e20f2663d1c9ee494af5d93c014c7
2016-11-10xmlsecurity PDF sign: support non-compressed AcroForm objectsMiklos Vajna1-8/+20
This was the last problem to be able to counter-sign Acrobat-created PDF 1.6 signatures unlimited number of times. Change-Id: I24ab80c8516b6fe9c08d57c08907bec70384dc28 Reviewed-on: https://gerrit.libreoffice.org/30757 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-11-10xmlsecurity PDF verify: fix incremental updates vs object streamsMiklos Vajna1-19/+18
The problem: an object stream provies obj#1 and obj#2, then an incremental updates provides an updated obj#1'. Then we look up obj#2, parse the stored objects on-demand, so at the end when later we look up the first object, we find obj#1, not obj#1'. An easy workaround would be to never update already existing objects from object streams, but that would break when an incremental update provides an object stream. Fix the problem by parsing stored objects right after tokenizing the object stream, and not later, on-demand, when we no longer have the context what objects should be ignored. This is needed (but not enough) to correctly append a signature at the end of a PDF file that has both object streams and incremental updates. Change-Id: I3c1fae5ac26804c8e8cc1984511f43cfa881c97b
2016-11-10xmlsecurity PDF verify: fix reading multiple subsections from an xref streamMiklos Vajna1-87/+105
This is especially needed, as we don't bother compressing updated objects into sections on signing, we simply use a separate section for each updated object. Work towards supporting xref streams and incremental updates at the same time. Change-Id: Ie9759edbba816991615fafc6602cdd440141b989
2016-11-10xmlsecurity PDF sign: use a predictor when compressing the xref streamMiklos Vajna1-5/+30
With this our xref stream output is close enough to Acrobat so that the existing signature verifier runs without any problems. Change-Id: I6eca7966890365759c269b465e4bf4d86d335219
2016-11-09xmlsecurity PDF sign: compress the xref streamMiklos Vajna1-1/+13
This way it's a bit smaller for large files and our output is closer to what Acrobat produces. Change-Id: Ide5f7b58a74a9d6ad7d806814eb57cb6931023cc Reviewed-on: https://gerrit.libreoffice.org/30726 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-11-09xmlsecurity PDF sign: improve suggested signature IDMiklos Vajna1-2/+21
So that when we have a single signature with ID="Signature2", then we use "Signature3" for the next ID, not "Signature2". (Acrobat uses that ID for the first signature.) Change-Id: I7032fbf014184da2a5be24730a92abc32a9a1258 Reviewed-on: https://gerrit.libreoffice.org/30725 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-11-09xmlsecurity PDF sign: conditionally write xref streamMiklos Vajna1-61/+178
In case the input document used a PDF 1.5 xref stream, not an old xref table, then write that as part of the incremental update. Acrobat seems to require this. Change-Id: I9f1f73140c26308f8720aa1ffe1b905d0e60ede0 Reviewed-on: https://gerrit.libreoffice.org/30724 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-11-09xmlsecurity PDF sign: handle when Catalog's AcroForm is an indirect dictionaryMiklos Vajna1-30/+111
Normally it's a direct dictionary, but it's OK to have it as a reference, and then the referenced object is a dictionary. Change-Id: If09edaf23501883be68148e430c42e721ec68247 Reviewed-on: https://gerrit.libreoffice.org/30719 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-11-09xmlsecurity PDF sign: handle when Page object's Annots is an indirect arrayMiklos Vajna1-33/+82
Normally it's a direct array, but it's OK to have it as a reference, and then the referenced object is an array. Change-Id: I191150632c2d8317ee6fd8c8169a90996298faa4 Reviewed-on: https://gerrit.libreoffice.org/30718 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-11-08xmlsecurity PDF verify: fix handling of xref stream free objectsMiklos Vajna1-3/+14
In case our xref table doesn't have an entry for "free" object types, then the table size won't provide a valid id for a next object. That resulted in creating all new objects with the same ID. With this, our verifier at least can see the new signature when appending one to a signed PDF 1.6 file. Change-Id: Iac39a400706cfcd23dd814d2b81cb8b950c69fc6 Reviewed-on: https://gerrit.libreoffice.org/30704 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-11-08xmlsecurity PDF sign: handle xref stream when reading trailerMiklos Vajna1-6/+23
Don't give up signing just because PDF 1.4 trailer is missing, provided that PDF 1.5 xref stream is available. Change-Id: I03360d428346537583a4398aa3a94b195b428713 Reviewed-on: https://gerrit.libreoffice.org/30703 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-11-08xmlsecurity PDF sign: don't crash on missing trailerMiklos Vajna1-0/+5
This will need cross-reference stream write support, just don't crash for now. Change-Id: Id48c131b22d4ed96174693f3e96b14c273d596a8 Reviewed-on: https://gerrit.libreoffice.org/30702 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-11-07Fix typos (also in the code)Andrea Gelmini1-2/+2
Change-Id: I45d45513b102f4fdcb55e8de20b95b37f66ea463 Reviewed-on: https://gerrit.libreoffice.org/30658 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2016-11-04xmlsecurity PDF NSS verify: handle SHA1_WITH_RSAMiklos Vajna1-2/+15
SHA1_WITH_RSA is a signing algorithm, not a digest one, but let's accept it, so LO on Linux can verify a signature generated by LO on Windows. It's annoying that equivalent mapping in NSS is not part of their public API. Change-Id: I97186fcc1d118f922e5ee3cb472aa5b52bc4b5ca
2016-11-04vcl: extract PDFWriter::GetDateTime() from PDFWriterImplMiklos Vajna1-0/+6
And use it in xmlsecurity when signing an existing PDF. This is especially important on Windows, where the PKCS#7 blob doesn't have an (unsigned) timestamp. Change-Id: I4051dc19a43f8f8114d9f4d02309f28d6754e9ae
2016-11-03xmlsecurity PDF sign: enable unit tests on WindowsMiklos Vajna1-2/+2
Now that the mscrypto part of PDFDocument::ValidateSignature() is implemented it's possible to run these tests on Windows as well, provided the machine has at least one signing certificate installed. Also fix a race, where the workdir of the signing test was used by the pdfsigning test. Change-Id: I80bbfbb5dc4baa400f9a6b85961883a247b0f22b
2016-11-03xmlsecurity PDF verify: initial Windows supportMiklos Vajna1-0/+121
The timestamp isn't extracted yet, but the digest match is already checked correctly and the certificate is exposed. Change-Id: Ieca002a5c4ca0b96f4dc397c460adb7f88f5ffc7 Reviewed-on: https://gerrit.libreoffice.org/30499 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-11-02xmlsecurity PDF verify: add support for object streamsMiklos Vajna1-114/+325
Adobe Acrobat uses object streams (PDF 1.6) when it signs a PDF exported from LO (PDF 1.4), with this we can verify that signature. If the PDF had at least one signature in LO, then the doc is not upgraded from PDF 1.4, so that was working already. Change-Id: I54b4447ca965a8ba1ffc69bde228ab6f0bda59ee
2016-11-01style fixes for cppcheck noExplicitConstructorJochen Nitschke1-4/+4
Change-Id: I2a690caea7656f2a18beb6d09f53154178a30f34 Reviewed-on: https://gerrit.libreoffice.org/30460 Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de> Tested-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-24 01:47:59 +0000