summaryrefslogtreecommitdiff
path: root/xmlsecurity
AgeCommit message (Collapse)AuthorFilesLines
2021-04-16xmlsecurity: replace OOXMLSecParser implementationMichael Stahl2-234/+1309
This is similar to 12b15be8f4f930a04d8056b9219ac969b42a9784 and following commits, but OOXMLSecParser has some differences to XSecParser, such as using a ds:Manifest, and requires a couple extra namespaces. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113381 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit cc1d19f7bbaefa5fb22ebd1344112755068b93c9) Change-Id: I56e39d9609db8fcad50ca1632ff482c1f0a30ff5
2021-04-16xmlsecurity: improve handling of multiple X509Data elementsMichael Stahl19-201/+641
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) Change-Id: I9633a980b0c18d58dfce24fc59396a833498a77d 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)
2021-04-16oox, svx, sw, xmlsecurity: clang-format these filesMiklos Vajna1-72/+126
I added these files more or less recently and they have long lines. Use clang-format to break at a sane column limit. Change-Id: Id4ef832e4843fc81f4a497385e49ccb835a7197f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94503 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 868acbd97b58b200731ca25ece4019de734e5726)
2021-04-16Remove unnecessary if blockSamuel Mehrbrodt1-64/+66
And format code inside Change-Id: Ied0d98935134bf6f7bc8c929645ad5faac9affa3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93116 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit cf36fe5eb41910c26d58fb25e54ccf2e0ee01365)
2021-04-16xmlsecurity: ignore elements in ds:Object that aren't signedMichael Stahl4-90/+221
Change-Id: I2e4411f0907b89e7ad6e0185cee8f12b600515e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111253 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 2bfa00e6bf4b2a310a8b8f5060acec85b5f7a3ce) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111909 Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 94ce59dd02fcfcaa1eb4f195b45a9a2edbd58242)
2021-04-16xmlsecurity: XSecParser confused about multiple timestampsMichael Stahl7-78/+63
LO writes timestamp both to dc:date and xades:SigningTime elements. The parser tries to avoid reading multiple dc:date, preferring the first one, but doesn't care about multiple xades:SigningTime, for undocumented reasons. Ideally something should check all read values for consistency. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111160 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 4ab8d9c09a5873ca0aea56dafa1ab34758d52ef7) xmlsecurity: remove XSecController::setPropertyId() Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111252 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit d2a345e1163616fe3201ef1d6c758e2e819214e0) Change-Id: Ic018ee89797a1c8a4f870ae102af48006de930ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111908 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit abe77c4fcb9ea97d9fff07eaea6d8863bcba5b02)
2021-04-16xmlsecurity: replace XSecParser implementationMichael Stahl2-346/+1341
Implement Namespaces in XML and follow xmldsig-core and XAdES schemas. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110833 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 12b15be8f4f930a04d8056b9219ac969b42a9784) xmlsecurity: move XSecParser state into contexts Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111158 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit 59df9e70ce1a7ec797b836bda7f9642912febc53) xmlsecurity: move XSecParser Reference state into contexts Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111159 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> (cherry picked from commit cfeb89a758b5f0ec406f0d72444e52ed2f47b85e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111907 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit ad5930e87e788780a255523f106deb1dde5d7b37) Change-Id: I03537b51bb757ecbfa63a826b38de543c70ba032
2021-04-16expand out some namespace aliases [xmlsecurity/source/helper]Noel Grandin4-123/+107
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94093 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> (cherry picked from commit 943fbfad668da76f7d0ebd4f4d8cdd67224d2f01) plus one line in xsecverify.cxx from: commit f59d9e7ea09482c2e9e5f52a8d0445e4cebc3df5 Author: Noel Grandin <noel.grandin@collabora.co.uk> AuthorDate: Fri Apr 3 15:53:49 2020 +0200 new loplugin:unusedvariableplus a particularly aggressive checker, which is why it is off by default Change-Id: I5fdb554a1b116824843f35645bc1cea3ca91e0f2
2021-04-16do same set error state as ReadAndVerifySignature doesCaolán McNamara1-0/+1
this function is nearly exactly the same as ReadAndVerifySignature except it doesn't set error-state on exception during parse Change-Id: Ife881f639a11d3185920ca62cc2cd22812fae36d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112366 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112412 (cherry picked from commit 52a23d595b820cab27d76d0e7c129f2757c762d6)
2021-03-18default to CertificateValidity::INVALIDCaolán McNamara1-2/+2
so if CertGetCertificateChain fails we don't want validity to be css::security::CertificateValidity::VALID which is what the old default of 0 equates to notably commit 1e0bc66d16aee28ce8bd9582ea32178c63841902 Date: Thu Nov 5 16:55:26 2009 +0100 jl137: #103420# better logging turned the nss equivalent of SecurityEnvironment_NssImpl::verifyCertificate from 0 to CertificateValidity::INVALID like this change does Change-Id: I5350dbc22d1b9b378da2976d3b0abd728f1f4c27 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110561 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-01-07officecfg,unotools,cui: add ODF 1.2 Extended / ODF 1.3 versionsMichael Stahl2-6/+6
... to configuration and UI. The new default is ODF 1.3 Extended, which is now ODFVER_LATEST and stored as value "3" in configuration. Adapt a few places related to DocumentDigitalSignatures etc. to new default. Change-Id: I420da4f7787cc864c6bd88470d61b146b9399aa1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93177 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2021-01-07xmlsecurity: actually validate in testODFEncryptedGPGMichael Stahl1-0/+1
Follow-up to 5eda583443cd0ec323e925395ea734c20fdbcf13 Change-Id: Icde98be0a8dccc58ca7c7c260e387bafb7f05b46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94412 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2021-01-07replace hard-coded "1.2" ODF version stringsMichael Stahl1-2/+2
Most of these are calls to DocumentDigitalSignatures::createWithVersion(), where it doesn't make a difference if "1.2" or "1.3" is passed in but maybe it will be different with "1.4". There is another ctor createDefault() which looks appropriate for non-ODF contexts and can also be used when no actual signing or verifying is done. In cases where there's an actual document its Storage has the version. Change-Id: Id636bbf965d9f96c7ed5f50774c509032525b2b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93091 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2021-01-07package: OFFICE-3940 ODF 1.3 export of OpenPGP encryptionMichael Stahl1-0/+17
Import was implemented with a7bf6488ebb544e1efaed0a1e53073df9cc2064d but it doesn't correspond to the schema so see previous commit. Change-Id: Ic19db07da20e88d6533509217a70983938e61beb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93088 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-11-20Avoid unused parameter warning in the !HAVE_FEATURE_PDFIUM caseTor Lillqvist1-0/+1
Change-Id: I218265f0bda7cdfcae523ea386edaec1a9143cef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106283 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-11-19xmlsecurity: reject a few dangerous annotation types during pdf sig verifyMiklos Vajna3-5/+74
(cherry picked from commit f231dacde9df1c4aa5f4e0970535c4f4093364a7) Conflicts: include/vcl/filter/PDFiumLibrary.hxx xmlsecurity/source/helper/pdfsignaturehelper.cxx xmlsecurity/source/pdfio/pdfdocument.cxx Change-Id: I950b49a6e7181639daf27348ddfa0f36586baa65 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106170 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-19xmlsecurity: handle MDP permission during PDF verifyMiklos Vajna6-15/+38
(cherry picked from commit 586f6abee92af3cdabdce034b607b9a046ed3946) Conflicts: include/vcl/filter/PDFiumLibrary.hxx vcl/source/pdf/PDFiumLibrary.cxx xmlsecurity/source/helper/pdfsignaturehelper.cxx (cherry picked from commit 00479937dc071246cc27f33fd6397668448a7ed9) Change-Id: I626fca7c03079fb0374c577dcfe024e7db6ed5b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106067 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-10-02Fix libnssckbi not found error on AndroidMert Tumer1-1/+1
This error causes Android App to be unable to open Password-protected documents. Change-Id: Iacbacb1c780025752e2447db325b075c58947818 Signed-off-by: Mert Tumer <mert.tumer@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103708 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-09-22tdf#128136: Build curl, nss, and xmlsec for iOS, tooTor Lillqvist1-1/+7
We must link nss statically, including the three dylibs that normally are loaded at run-time, because including bare dylibs in an iOS appp on the App Store is not OK. See https://developer.apple.com/forums/thread/125796 . For linking the softokn3 library statically, NSS already had code, behind NSS_STATIC_SOFTOKEN ifdefs. Introduce two more macros: NSS_STATIC_FREEBL for the freebl library and NSS_STATIC_PKCS11 for the nssckbi library. Turn off parallelism for the sub-make building nss. There seems to be race conditions or something when running simultaneous instances of the nsinstall.py script or the nsinstall program in nss (used when building nss for the build platform). When cross-compiling from macOS, use python3 to run the nsinstall.py script, as it is Python 3. Change-Id: Idd427b5ebf21f802b3feb0d5a3d259317ba8fc67 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103106 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-09-19Avoid unused parameter 'rPageChecksums' in the !HAVE_FEATURE_PDFIUM caseTor Lillqvist1-0/+1
Change-Id: I9fa471d9f464f6754f34d0879a1ef90515f18625 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103026 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-09-09xmlsecurity: pdf incremental updates that are non-commenting are invalidMiklos Vajna5-3/+92
I.e. it's OK to add incremental updates for annotation/commenting purposes and that doesn't invalite existing signatures. Everything else does. (cherry picked from commit 61834cd574568613f0b0a2ee099a60fa5a8d9804) Change-Id: I4607c242b3c6f6b01517b02407e9e7a095e2e069 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102327 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-08xmlsecurity: avoid saying OK when the signature is partialMiklos Vajna2-7/+12
That's reserved for valid signatures (digest match, certificate validates and the signature covers the whole document). Also avoid "invalid" in the dialog when the digest matches and the signature is just incomplete. This now uses wording which is closer to Acrobat and also uses the same wording on the infobar and in the dialog. Change-Id: I26e4781d555b65cf29aa8df2232e286917235dc1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102236 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-07xmlsecurity: fix infobar vs signature dialog inconsistencyMiklos Vajna1-2/+11
The infobar mentioned if a signature is partial, but the dialog just has a bool UI for signatures. Then present "good, but partial" as "bad". (cherry picked from commit 3ba1144cb96c710e665ffb3ada26fb6a48a03472) Change-Id: I698190aa77702000b11d635bd038d9c9a91614ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101844 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102145 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-19Make TempFile destructor remove temp directory recursivelySamuel Mehrbrodt1-60/+0
Change-Id: Idcfa93ffe86112477ad81bcbf74b8e5b858423f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87080 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit 4a25fb867f7cc0a0fc21c4079c84fadec6647ad1) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100880 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-07-27xmlsecurity: detect unsigned incremental update between signaturesMiklos Vajna6-33/+139
(cherry picked from commit 7468d5df5ec79783eae84b62bdc5ecf12f0ca255) Conflicts: xmlsecurity/source/pdfio/pdfdocument.cxx Change-Id: I269ed858852ee7d1275adf340c8cc1565fc30693 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99478 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-29sd signature line: pass the model down to xmlsecurityMiklos Vajna5-23/+63
So it can avoid SfxObjectShell::Current(), which is only correct when a single document is open. Also add an sfx2::DigitalSignatures interface so this can be done without UNO API changes. (cherry picked from commit c3f8702241b625db994bcb059d8c91c25fd43e53) Conflicts: xmlsecurity/source/component/documentdigitalsignatures.cxx xmlsecurity/source/helper/documentsignaturemanager.cxx Change-Id: Ie81996b8f1e8851975b27c43a53f9d23e316004e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97258 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-29[API CHANGE] extend css.security.XDocumentDigitalSignaturesbrinzing1-2/+45
Add support for macro and package signing with a provided certificate which is already possible for document signing since LO 6.2: boolean signScriptingContentWithCertificate( [in] ::com::sun::star::security::XCertificate xCertificate, [in] ::com::sun::star::embed::XStorage xStorage, [in] ::com::sun::star::io::XStream xStream); boolean signPackageWithCertificate( [in] ::com::sun::star::security::XCertificate xCertificate, [in] ::com::sun::star::embed::XStorage xStorage, [in] ::com::sun::star::io::XStream xStream); (cherry picked from commit 697989d11e25b3eb83e5ca2dad5d71b178abfbc1) Change-Id: I9783cd317a7202691913be186eca95964b1e0ff7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97257 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-29sd signature line: place shape on the correct pageMiklos Vajna1-2/+32
PDFDocument::Sign() had this hardcoded to always place the signature widget on the first page, add a way so that xmlsecurity/ can tell the pdf signing code to put it on an other page. This way in case the user created the signature line shape on the Nth page, it'll end up on the Nth page of the PDF result as well, as expected. (cherry picked from commit 022f6bb1f7ed06edb126a2b85719d8622104bb57) Conflicts: vcl/Module_vcl.mk Change-Id: I63decba98774151e9634ea924c2fed0f7814cb28 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97256 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-29Move data for signing tests to test/Miklos Vajna10-68/+12
This was duplicated under xmlsecurity and made it hard to have test code outside xmlsecurity, even if the core of the pdf signing is nowadays under svl/. (cherry picked from commit 81c0b6410ae7a604a97994c7f31113f24665167f) Conflicts: include/unotest/macros_test.hxx unotest/source/cpp/macros_test.cxx xmlsecurity/qa/unit/pdfsigning/pdfsigning.cxx Change-Id: If5ce8269bb72f503263727d8255fe856742dfa60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97253 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-29sd signature line: add testcaseMiklos Vajna3-0/+79
Fails with commit 9b7a890fd59744459692d7f66402c6bdd25acec4 (sd signature line: include shape in the appearance widget, 2020-06-19) reverted. (cherry picked from commit fb8f0ef26d57986bd27c6c5088939c32453e6b06) Change-Id: Ib237774374553af5d37c9deaffdea6fae65a28f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97252 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-29sd signature line: access the pdf shape from the appearance writerMiklos Vajna1-0/+4
PDFDocument::WriteAppearanceObject() is where we can turn the pdf data (containing a single shape only) into a form XObject, later. (cherry picked from commit 058c21ac4a552ee6f6ca2f67c0d134a819228d53) Change-Id: Id042c95af4a867d3997d6f7742a18659b8925c12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97243 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-29sd signature line: export shape with signature to PDFMiklos Vajna2-2/+76
So that later this can be used when writing the appearance object of the pdf signature. (cherry picked from commit 559765ca62f5e581dd5040bdf24e504cf38b0397) Change-Id: I98517b88723de8ffdc982d4eaae7225289603f1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97242 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-05-24package: OFFICE-3940 ODF 1.3 import of OpenPGP encryptionMichael Stahl1-0/+0
This was supposed to be implemented by commit a7bf6488ebb544e1efaed0a1e53073df9cc2064d "ODF1.3: import new OpenPGP encryption markup" but it turns out that the ODF 1.3 cs01 schema differs from the implementation: in ODF 1.3 cs01 we have <manifest:encrypted-key> <manifest:encryption-method .../> <manifest:keyinfo> <manifest:PGPData> </manifest:PGPData> </manifest:keyinfo> <manifest:CipherData> </manifest:CipherData> </manifest:encrypted-key> whereas the implementation expects <manifest:keyinfo> <manifest:encrypted-key> <manifest:encryption-method .../> <manifest:PGPData> </manifest:PGPData> <manifest:CipherData> </manifest:CipherData> </manifest:encrypted-key> </manifest:keyinfo> Ideally the inner manifest:keyinfo should be manifest:KeyInfo but not sure if that really matters. Change-Id: I407321c857e7b3ed9f4d04568ca2ea116764b3da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94309 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 4f1b0f7d5235140611305b784b58f95fc5b8bd81) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94586 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-04-29tdf#131733 Show only CN part of X.509 subject infocp-6.4-branch-pointGabor Kelemen4-9/+9
The problem was that the whole Subject info was returned from X.509 certs if they did not start with one of "CN", "OU", "O", "E" Instead of extending this list with random keys, pass the type of cert and only return the whole Subject info if it's an OpenGPG one, and process the info unconditionally if it's X.509 like before the OpenGPG integration Change-Id: I1aa5d7285e48b0f4a769a073cdfb7732e482792c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92675 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit bedba76adb9b1421a7d939cfef44b8194e987888) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93129
2019-12-17Fix macro security UI usability problemsJan-Marek Glogowski4-19/+66
* Don't hide the option dialogs "Macro security" push button. I don't see any reason, why these settings should be hidden, if macros are disabled or settings locked. At least a user can now check, what is going on (still nothing shows disabled macros for a document in the UI AFAIK). * Don't scale the lock icons of the trusted list boxes. This just uses the same alignments, which the macro security level lock image uses, otherwise the image is scaled to fit the whole space of its layout cell. * Don't disable the trusted list boxes. If the setting is locked, it's sufficient to disable all the buttons, which allow modification (so View can stay enabled). This way you can still scroll the list. Correct button handling is already implemented and works for me. * Catch exceptions of broken certificate data. If your config contains certificates, which can't be correctly decoded, the NSS backend will throw an exception, which kills the dialog, but not the nested loop, resulting in a locked LO. Also show an error dialog with the broken base64-encoded data. Change-Id: I79002e0ce85cf9a9017caf858407f2f635a3a074 Reviewed-on: https://gerrit.libreoffice.org/85056 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit b3348ce498b3d54b3e5e6518954ad9d5e917b8f2) Reviewed-on: https://gerrit.libreoffice.org/85282
2019-11-11remove a PCH for which the library has already been removedLuboš Luňák2-46/+0
Change-Id: Ida35d27a4aaae1c137e3ed072dff62b7c7e894ca Reviewed-on: https://gerrit.libreoffice.org/82399 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-11-05make some classes module-privateNoel Grandin5-5/+5
Change-Id: Ice9a57eedb166672dbdfae6da2a172ab77566a19 Reviewed-on: https://gerrit.libreoffice.org/81983 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-03loplugin:stringaddNoel Grandin1-3/+1
tweak the plugin to be more permissive, then validate by hand afterwards Change-Id: I40c5c911fe6ff7e45baaca372abf7dac211d9654 Reviewed-on: https://gerrit.libreoffice.org/81942 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-03find symbols that can be privateNoel Grandin2-8/+8
update the script and make private standalone functions Change-Id: Icb26ce258107700c90f89ad4e0d3329d075a2eb1 Reviewed-on: https://gerrit.libreoffice.org/81879 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-31Fix StringAdd::isCompileTimeConstantStephan Bergmann1-4/+2
...to find StringLiteral on the RHS of +=. Which revealed that the VisitCompoundStmt/checkForCompoundAssign logic needed to be fixed, too, so that s += side_effect(); s += "literal"; s += side_effect(); only gets combined to s += side_effect() + "literal"; s += side_effect(); and not all the way to s += side_effect() + "literal" + side_effect(); Change-Id: I432e3458b933a7d0ad6141c747b675cc8b0f0ba4 Reviewed-on: https://gerrit.libreoffice.org/81804 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-18make bin/update_pch.s always include code in trivial #if'sLuboš Luňák2-4/+25
E.g. #ifdef LIBO_INTERNAL_ONLY is always true for code that builds with our PCHs. Change-Id: I3cf311ea3621b909105754cfea2cb0116b8b67f5 Reviewed-on: https://gerrit.libreoffice.org/80961 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-17Remove some memset callsMike Kaganski1-2/+1
Replace them with default initialization or calloc Change-Id: I747f53c2ced2d0473fd5a5ede4f8520a0633dcc1 Reviewed-on: https://gerrit.libreoffice.org/80805 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-16tdf#42316 handle saving to template filtersJan-Marek Glogowski1-18/+163
This extends the filter comparison from commit c3a1c83ff5af ("tdf#42316 preserve macro signature of templates"). The original patch just stripped "_template" from the source filter to find equal document types, which just enables the "template => document" case. This patch also strips the "_template" from the target filter, which fixes the "document or template => template" cases. This also extends the signing save tests: * OTT 1.2 => OTT 1.2 - preserve * ODT 1.2 => OTT 1.2 - preserve * OTT 1.0 => OTT 1.0 - preserve * ODT 1.0 => OTT 1.0 - preserve * OTT 1.0 => OTT 1.2 - drop Change-Id: Ie297258a4d9f9aa4beb25786c6ba240b6f16f49b Reviewed-on: https://gerrit.libreoffice.org/80654 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2019-10-14loplugin:stringadd look for unnecessary temporariesNoel Grandin1-1/+1
which defeat the *StringConcat optimisation. Also make StringConcat conversions treat a nullptr as an empty string, to match the O*String(char*) constructors. Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b Reviewed-on: https://gerrit.libreoffice.org/80724 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-10Silence -Werror,-Wunused-variable (clang-cl)Stephan Bergmann1-1/+1
Required a workaround for loplugin:indentation, until <https://reviews.llvm.org/D68581> "Include leading attributes in DeclStmt's SourceRange" lands in Clang. Change-Id: I7192969d40fa4c50bbd603d059532b9344865248 Reviewed-on: https://gerrit.libreoffice.org/80596 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-09tdf#114441 changed some sal_uLong to better fitting typesChristian Barth1-1/+1
Change-Id: I114a6b028eb59a1ae38c31bc20439a35643fe972 Reviewed-on: https://gerrit.libreoffice.org/80159 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-10-08loplugin:redundantpointerops simplify *p.get()Noel Grandin1-1/+1
Change-Id: I12517651fb3f777fd08e384992bb3e84b340ad85 Reviewed-on: https://gerrit.libreoffice.org/80382 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-06Related: tdf#127935 set default activate handler to toggle row expansionCaolán McNamara4-4/+6
Change-Id: I2bbfb1445b8d2e748f642cdf4723d41b7f072e2b Reviewed-on: https://gerrit.libreoffice.org/80305 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-10-01loplugin:stringconstant (clang-cl)Stephan Bergmann5-6/+6
Change-Id: Id1a82cea4444255fdb693e126b7571a406094624 Reviewed-on: https://gerrit.libreoffice.org/79916 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-01add activates_default to GtkEntries in dialogsCaolán McNamara1-5/+7
activates-default of True means pressing return activates the default button of the action area, which is typically what vcl Edit did by default. Change-Id: I60bc1634b04a486af86526d887d0ada961b08076 Reviewed-on: https://gerrit.libreoffice.org/79860 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>