summaryrefslogtreecommitdiff
path: root/xmlsecurity
AgeCommit message (Collapse)Author
2016-10-29crashtesting: piles of pdf import crashesCaolán McNamara
e.g. ooo112863-2.pdf Change-Id: I359f7e50f416f0a756e16099cdf47be3b1c32d90
2016-10-28xmlsecurity PDF verify: start using offsets from xref streamsMiklos Vajna
This is needed (but not enough) to verify PDF 1.5 signatures. What's missing next is support for object streams. Change-Id: I5afec0a77839ffabe0aaa07e367064210535a1a9
2016-10-28xmlsecurity PDF verify: initial support of cross-reference streamsMiklos Vajna
This adds support for cross-reference streams (which can be used instead of plain-text cross-reference tables) + also one stream predictor. The actual parsed data is still not used, though. Change-Id: Ia806abd8a97636a1bd25dfdafea377b088800f00
2016-10-28Bin one more pointless TAG_ macroTor Lillqvist
Change-Id: I78e85923e2c5da366c0bec0812c8fe0240310b67
2016-10-28Bin unnecessary TAG_ and ATTR_ macros and expand in-placeTor Lillqvist
They just make grepping harder, and don't really avoid a risk of mistyping. For instance, there were both TAG_TRANSFORM and TAG_TRANSFORMS (with values "Transform" and "Transforms"), so if you think you are likely to misspell "Transforms" as "Transform", you are as likely to misspell TAG_TRANSFORMS as TAG_TRANSFORM. Typos affecting generated XML should be catched by unit tests anyway. Some of the (newer) code here is already in this style, using string literals directly for tags and attributes, so this change just makes the style more uniform. I did not touch the macros that have long URIs as value. For them there is some usefulness in having the shorter macros in the code. (But the names of the ALGO_* macros are not consistently constructed from the URIs.) Change-Id: I9130395f45fafc13fb2a6ac47e98177647e27cf9
2016-10-27xmlsecurity PDF verify: handle missing trailerMiklos Vajna
Support for Cross-Reference Streams is still missing, but this avoids a crash at least. Change-Id: I8c5d16531f8603feeebe8feddb7c3bdfa61943cb
2016-10-27xmlsecurity PDF verify: import out-of-signature dateMiklos Vajna
The signature date can be placed as the value of the "M" key, and also inside the signed PKCS#7 binary. When the later is missing show what's described in the previous. Change-Id: Idb40d91adb70486bc1f19d4755a3f8e17d35e9e9
2016-10-27xmlsecurity PDF verify: support array ref annotationsMiklos Vajna
Each pdf signature is mentioned in the Annots key of a page object. Usually the key contains an array value. But it's valid for the key to contain a reference to an object, where the object contains the actual array, so support this case as well. Also: - stop parsing name tokens on the first seen '(' character (usually there is a whitespace between the two, but that's not required) - handle \0 characters in the last 1024 bytes of the document by using std::search() instead of strstr(). Change-Id: I3a167b23340230f99f1ae4112473ed10e1c96b09
2016-10-27Sorry, could not resist: Bin pointless variablesTor Lillqvist
We should also just use the string literals as such in the code (some newer parts of this module already does that), and not hide them behind preprocessor macros. An Easy Hack? Change-Id: I3ab5793ff265a4aceff2fed1562a54bfb0ce3ccb
2016-10-26xmlsecurity PDF verify: support SHA-256Miklos Vajna
And various other minor fixes. Change-Id: Ifcccebf48aac8ad526406f2d7a402a840d3c91cd
2016-10-26xmlsecurity PDF verify: fix handling of non-imported certsMiklos Vajna
Previously we only managed to verify a signature in case the certificate was already imported in the local NSS db. Don't depend on that by (temporarily) importing certificates from the PDF signature. Also adjust a test file that failed previously (the test DB has only an "Alice" cert imported, intentionally sign the file as "Bob" as well). Change-Id: Id8440acc31915f5a1718ea48129b950bb67e7486
2016-10-26xmlsecurity PDF sign: fix removing non-last signaturesMiklos Vajna
PDF signatures are always chained, so when removing a signature not only the item at a given position should be removed on the UI, but the whole position-last range. Change-Id: I76b14308885267cdac994fa957218a8b7df6b3cf
2016-10-26xmlsecurity PDF signing: fix byte range check for multiple signaturesMiklos Vajna
We can mandate that the byte range end is the end of the file for the last signature only. With this, signing a previously unsigned file multiple times works, so add a matching testcase for that as well. Change-Id: I8fe5482890fca4dab8da6305aa7fc7f60df612d8
2016-10-26xmlsecurity PDF signing: only write incremental xref in an incremental updateMiklos Vajna
We used to just dump all the object offsets in the xref of the incremental update, but Adobe Acrobat doesn't like that, and considers that a second signature invalidates the first. If we properly only mention new and changed objects in the xref, then this doesn't happen. This requires actually parsing incremental updates, the previous code depended on LO writing not-really-incremental xrefs at the end of incremental updates. Change-Id: Icdd73fe0a3eab16f8c5a62f1355edbb49f6e73de Reviewed-on: https://gerrit.libreoffice.org/30288 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-26xmlsecurity PDF sign: use unique ID for a new signatureMiklos Vajna
Otherwise Adobe Acrobat thinks they are different versions of the same signature. Change-Id: I454c7d87106e348fd70f18fad83f2c3aeda29dff Reviewed-on: https://gerrit.libreoffice.org/30278 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-25xmlsecurity PDF sign: append reference to the Catalog's AcroForm keyMiklos Vajna
Similar to the Page object's Annots key, but here we want to append our reference to the nested AcroForm/Fields key, so that needs more infrastructure. This is also needed (but not enough) to be able to sign a PDF document multiple times. Change-Id: I4d5e2aa8f49d2181a15cbf7c4e27577fc98b547d Reviewed-on: https://gerrit.libreoffice.org/30267 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-25xmlsecurity PDF sign: append reference to the Page's Annots keyMiklos Vajna
Previously we assumed that the Page object's dictionary has no Annots key. Now detect if that's not true, and in that case don't just copy of the whole dictionary (as part of the incremental update), instead copy it in two steps, so we can insert our reference in the middle. This is needed (but not enough alone) to be able to sign a PDF document multiple times. Change-Id: Ia5bf993320428eef80551e7e9cc7bfb2b858db7f Reviewed-on: https://gerrit.libreoffice.org/30257 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-25xmlsecurity: add PDF signature removal testcaseMiklos Vajna
This one needs no access to private test keys, so no workaround is needed for older NSS. Change-Id: Ia233901658832cf55157511b4c5b5c2ccb243425
2016-10-25-Werror,-Wunused-variableStephan Bergmann
Change-Id: I55a0388838a7b9aebc6fd07c92e4d1a8081a4fb6
2016-10-25CppunitTest_xmlsecurity_pdfsigning: fix this on RHEL6Miklos Vajna
The pdfdocument problem is present only on 32bit. The pdfsigning problem is present on RHEL6, but not on RHEL7, for some reason NSS fails to parse the provided profile (generated by a bit newer NSS). Just return early in that case, we want to test the PDF code there, not NSS. Change-Id: I1123865d4b2176676a8fdaf648222fda8ca0b923 Reviewed-on: https://gerrit.libreoffice.org/30229 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-10-24Use an enum classTor Lillqvist
Change-Id: If75874ee12197edd367f5527a37e467041005794
2016-10-24Bin pointless macroTor Lillqvist
Change-Id: I460d5e7c431d2613999db86a73d4e14663ff038d
2016-10-24Bin pointless macroTor Lillqvist
Change-Id: Ia5829219eda13832857848267afae25167a31ab8
2016-10-24Indentation fixesTor Lillqvist
Change-Id: Ie0116a7c9c51268204647499b26f4247e55e0523
2016-10-24xmlsecurity: implement PDF signature removal UIMiklos Vajna
Unlike with ZIP-based storage, it can happen that the removal fails, so make sure we only remove the signature from the listbox when PDFDocument::RemoveSignature() succeeds. Change-Id: I3241fc11425686bc1ea5452b8f602e053aec0769 Reviewed-on: https://gerrit.libreoffice.org/30224 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-24Revert "Blind fix to TBs"Julien Nabet
This reverts commit f736c71dde8f4a84688b932b1531808d4c7cbd8c. Change-Id: I83df90a5fc6cefb4e0c4fdbb37fa46a546809b83 Reviewed-on: https://gerrit.libreoffice.org/30223 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2016-10-23Fix typosAndrea Gelmini
Change-Id: Ib7b17f85c7b6a1937c3f6e1617ceec58074643b4 Reviewed-on: https://gerrit.libreoffice.org/30040 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: jan iversen <jani@documentfoundation.org> Tested-by: jan iversen <jani@documentfoundation.org>
2016-10-23Blind fix to TBsJulien Nabet
Change-Id: I74165378255e3c844ee7f91a5d4eb09a573784bd Reviewed-on: https://gerrit.libreoffice.org/30179 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2016-10-21xmlsecurity: implement removal of a signature in pdfverifyMiklos Vajna
It's not exactly clear how one should guess what was file end before signing, for now assume the followings: - the file ended with a %%EOF, an optional \r, and a \n - the number of incremental updates is the same as the number of signatures When the later is not the case, don't attempt to remove the signature. Change-Id: I203a7b0605fc061ec6aacfde3a8eedc4736379f2 Reviewed-on: https://gerrit.libreoffice.org/30140 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-21xmlsecurity PDF export: fix missing /Prev key in the trailer dictionaryMiklos Vajna
"In addition, the added trailer dictionary shall contain a Prev entry giving the location of the previous cross-reference section." (ISO-32000-1, section 7.5.6). Add it, even if it seems Adobe Acrobat can live with not writing it. Change-Id: I1f53e75ebe7dba4b45b3cf1908b2d3b031ef6b02 Reviewed-on: https://gerrit.libreoffice.org/30133 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-21xmlsecurity: add PDF sign unit-testMiklos Vajna
If the NSS binary files ever need re-generating, it's just a copy from a fresh Firefox user profile, after importing 'example-xmlsecurity-Alice.cert.p12', as produced by './create-certs.sh'. Change-Id: Iabe15a816cb674d1691e3ff3e10aa2bd851f8e0d Reviewed-on: https://gerrit.libreoffice.org/30126 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-21cid#1374093 unreachable codeMiklos Vajna
Change-Id: Ib34aa7af7bdba304fe1f212d39c3c6de24e87a2d
2016-10-21xmlsecurity: export description in PDF signatureMiklos Vajna
Extract appendUnicodeTextString() from the PDF writer impl, and reuse it in xmlsecurity, to share code. Change-Id: Icdc2f89132cd29e07280001e30bad97e0a644654 Reviewed-on: https://gerrit.libreoffice.org/30110 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-20xmlsecurity: show PDF signature right after adding itMiklos Vajna
Also: - handle PDF in DocumentSignatureManager::write(), so the PDF file is not truncated when closing the document signatures dialog, and - handle PDF in DigitalSignaturesDialog::canAddRemove() Change-Id: I77c1fcdcbdcb079ce934f37546129d9d280e5d2e
2016-10-20xmlsecurity: add initial PDF sign UIMiklos Vajna
An unsigned PDF can be signed now, but the stream still gets truncated on closing the dialog. Change-Id: I12dd50bf577cd23b3355f6c6d03e71a9c0dbcfab
2016-10-20Extract vcl::PDFWriter::Sign() from vcl and xmlsecurityMiklos Vajna
The use case is different in vcl and xmlsecurity: vcl creates a new PDF (possibly with a signature), while xmlsecurity signs an existing PDF, but this part can be shared between the two. So far in vcl only the nss part is moved, not touching mscrypto yet. Change-Id: Ie776f622c1a4a3a18e79e78f68722a2fa219a83b Reviewed-on: https://gerrit.libreoffice.org/30063 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-19xmlsecurity: fix the PDF incremental update's cross-references tableMiklos Vajna
The VCL pdf export writes a space after the in-use entry, and turns out Adobe Acrobat starts to "repair" the file if there is no such space. Which means the signature is validated against the repaired document, resulting in a "The signature byte range is invalid" error message, hiding the root cause. Not that ISO-32000 7.5.4 "Cross-References Table" would mention the need for such whitespace at the end of the lines. Change-Id: I165b57809550f184f374c00f28426a3cd813c63f
2016-10-19cid#1374076 uncaught exceptionMiklos Vajna
Change-Id: Ifdbfc9f905f2ed7778830a0f2cc114d27feb36da
2016-10-19cid#1374075 uncaught exceptionMiklos Vajna
Change-Id: I1c95efb37e62c5e600607d23e4e80bf430854cae
2016-10-19cid#1374074 uncaught exceptionMiklos Vajna
Change-Id: Ibb734d394b49a032fab1dc1255376d6b7bb3632d
2016-10-18xmlsecurity: use NSS on Linux/macOS to generate pdf signatureMiklos Vajna
This is just the minimum so that our own PDF signature validation is happy. Change-Id: I1148817c11174fd4f9184d0ce2c0511e9d6bd11c Reviewed-on: https://gerrit.libreoffice.org/30018 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-18xmlsecurity: add signing stub in pdfverifyMiklos Vajna
It does (almost?) everything to add a valid signature, except the actual signature blob. Change-Id: I727770caef2335473a8dba29d60daf5a049129b9 Reviewed-on: https://gerrit.libreoffice.org/30001 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-10-18xmlsecurity: initial incremental update support in pdfverifyMiklos Vajna
I plan to use this for signing purposes, but so far what's implemented just writes out an incremental update at the end of the file, without actually updating much (just an unreferenced appearance object). Change-Id: I1cb40430ade6af0a25ff914ba4df670a77fcf457
2016-10-18loplugin:inlineablemethods in xmloffNoel Grandin
Change-Id: I22202f85c65a862ccdafe1d521e2945e3d99252a
2016-10-17replace <<= with assign for <<= with rhs AnyJochen Nitschke
makeAny and Any ctor return an Any Change-Id: Iaa361bc315d785f80153acf1009bf47d109728ec Reviewed-on: https://gerrit.libreoffice.org/29914 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
2016-10-17xmlsecurity: detect if PDF signature doesn't sign the whole fileMiklos Vajna
For ODF signatures we require that all streams of the storage are signed. The PDF equivalent of this is to ensure that the byte range is the entire file, including the signature dictionary but excluding the signature value itself. Change-Id: Ie47f42913e2aa960f35079eb981768cd47fb9f92 Reviewed-on: https://gerrit.libreoffice.org/29890 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-10-17xmlsecurity: verify certificate of PDF signaturesMiklos Vajna
We patch xmlsec to not verify certificates, and the PDF tokenizer in xmlsecurity doesn't do that, either. The point of doing so, is that the DocumentSignatureInformation UNO struct has separate CertificateStatus and SignatureIsValid fields for the validity of the certificate and the signature. That means the certificate has to be validated somewhere as well. ZIP-based formats do that in DocumentDigitalSignatures::ImplVerifySignatures(), and this commit implements the same for PDF signatures, too. Change-Id: Ic486afc8f392625b1efcad989fd9053b014a261b Reviewed-on: https://gerrit.libreoffice.org/29889 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-10-17xmlsecurity: check file header when reading PDF signatureMiklos Vajna
Currently the only non-ZIP-based import filter that declares the SUPPORTSSIGNING flag is PDF, so if we get a stream without a storage, we assume it's PDF. If any other non-ZIP-based format would add that flag in the future, that would mean PDFDocument::Read() gets that as an input. That means it makes sense to at least check the file header early in the tokenizer, and return early when that doesn't match. Change-Id: I8760d130c4211f37be705e03b22814825042cac8 Reviewed-on: https://gerrit.libreoffice.org/29888 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-10-17Executable_pdfverify: initialize nss / mscryptoMiklos Vajna
This was broken since commit 9fe910e4861a7911c6d286258a30954e715653ac (xmlsecurity: use common NSS init in PDFDocument, 2016-10-13), after that PDFDocument assumes that the client code does the crypto initialization. Change-Id: Iaee005afef6bd602c3a95e9a18f407c4d4223a26 Reviewed-on: https://gerrit.libreoffice.org/29887 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-10-15clang-cl loplugin: xmlsecurityStephan Bergmann
Change-Id: Ic101384ca32abb0d527f97d2cf695eb19c66da86 Reviewed-on: https://gerrit.libreoffice.org/29838 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2025-02-04 23:21:00 +0000