summaryrefslogtreecommitdiff
path: root/xmlsecurity/source
AgeCommit message (Collapse)Author
2020-11-19pdfium: add signature and trailer end getter wrappersMiklos Vajna
So PDFiumDocument::getPointer() can be retired. Change-Id: I77c34c3e263bd6f39e06e50f621f2eaff804c716 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106079 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-17loplugin:stringviewparam check methods tooNoel
not just functions Change-Id: Icca295dd159002b428b73f2c95d40725434f04d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105789 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-13xmlsecurity: verify signatures using pdfiumMiklos Vajna
And add a testcase with an odd PDF which were not handled by the old tokenizer but is handled by pdfium. Signature verification is happening implicitly while a document is opened, so it makes sense to use the more battle-tested pdfium to do this verification, instead of own code. (The APIs are somewhat low-level, so we can easily keep using our crypto stack for digest verification and our own certificate validation.) Signature creation still happens with the same own code, though. Change-Id: Ia64e84ab497422245e4ffd8a80a6a728cea84ff7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105766 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-11-05xmlsecurity: reject a few dangerous annotation types during pdf sig verifyMiklos Vajna
Change-Id: I950b49a6e7181639daf27348ddfa0f36586baa65 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105312 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-10-26switching long to a 64-bit type on 64-bit windowsNoel
(*) create a rewriting plugin to do most of the work, heavily based on the fakebool plugin (*) but there are still a number of "long"s in the codebase that will need to be done by hand (*) the plugin needs lots of handholding, due to needing to add #include and update macros Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-21xmlsecurity: clean up last raw pdfium callMiklos Vajna
Change-Id: I4e6f28ef181fff5b7fc431aa01763370bb48476d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104577 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-10-21Avoid unused parameter 'nMDPPerm'Tor Lillqvist
Change-Id: I3ae13c66d76a61e197f214b2ffa8299de89a7a53 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104612 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-10-20xmlsecurity: handle MDP permission during PDF verifyMiklos Vajna
Change-Id: I626fca7c03079fb0374c577dcfe024e7db6ed5b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104529 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-10-14More fixes of uses of now-explicit OUString ctor taking raw sal_Unicode pointerStephan Bergmann
...in Windows-only code, after c927aab29ebfff1ce3ac0b2f27ae343025a9890c "Make the OUString ctors taking raw sal_Unicode pointer/non-const array explicit". Interestingly, these occurrences were accepted by MSVC and only cause errors with clang-cl, so happened to go unnoticed until now. Change-Id: I33e7653e28a21541ef793b4b0750abb6037752db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104314 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-06loplugin:const* make some params and methods constNoel
Change-Id: Idec482c21c270912f9bcaeb980077c1616f67c8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104022 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-02Fix libnssckbi not found error on AndroidMert Tumer
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/+/103658 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-09-25xmlsecurity: fold pdfio into pdfsignaturehelperMiklos Vajna
Most of the initial pdfio was moved to vcl as vcl::filter::PDFDocument. A small part was left here, because it depended on NSS. Then later the NSS bits were moved to svl::crypto::Signing. The rest is just a small amount of code, keeping that separate from PDFSignatureHelper, which is its only user makes little sense. With this, vcl::filter::PDFDocument is an implementation detail of PDFSignatureHelper during signature verification. Change-Id: I6230f9e46deeff7159970f88dbb3bd2de0e9ce7d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103350 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-23Executable_pdfverify: use PDFSignatureHelper for signature verificationMiklos Vajna
Towards making vcl::filter::PDFDocument an implementation detail of PDFSignatureHelper during signature verification: so pdfverify, cppunit tests and the UI shares more code. Change-Id: Ibb68933d754e392bce0ebbf06be8916ab3f7efdc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103214 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-23tdf#128136: Build curl, nss, and xmlsec for iOS, tooTor Lillqvist
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> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103218 Tested-by: Jenkins
2020-09-19fix non-pdfium buildNoel Grandin
Change-Id: Ic1e30a412927748ba58a21cf2ee922cd1a490aa4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103040 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-17Remove some unused includesMiklos Vajna
Change-Id: I4a357ee2c542884149d7460bf2be66e5863fbaed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102882 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-06fix non-pdfium buildNoel Grandin
Change-Id: I996164480d75ca3739942f6a1c06bbb4a1c400d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102085 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-04xmlsecurity: pdf incremental updates that are non-commenting are invalidMiklos Vajna
I.e. it's OK to add incremental updates for annotation/commenting purposes and that doesn't invalite existing signatures. Everything else does. Change-Id: I4607c242b3c6f6b01517b02407e9e7a095e2e069 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102057 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-04Make many OUString functions take std::u16string_view parametersStephan Bergmann
...instead of having individual overloads for OUString, OUStringLiteral, and literal char16_t const[N]. (The variants taking OUString are still needed for !LIBO_INTERNAL_ONLY, though. The variants taking ASCII-only literal char const[N] are also left in place.) This nicely reduces the number of needed overloads. std::u16string_view allows to pass as arguments: * OUString * OUStringLiteral * OUStringChar (with the necessary conversion added now) * OUStringNumber * u"..." char16_t string literals * u"..."sv std::u16string_view literals * std::u16string, plain char16_t*, and more A notable exceptions is OUStringConcat, which now needs to be wrapped in OUString(...), see the handful of places that needed to be adapted. One caveat is the treatment of embedded NUL characters, as std::u16string_view(u"x\0y") constructs a view of size 1, while only u"x\0y"sv constructs a view of size 3 (which matches the old behavior of overloads for literal char16_t const[N] via the ConstCharArrayDetector<>::TypeUtf16 machinery). See the new checkEmbeddedNul in sal/qa/rtl/strings/test_oustring_stringliterals.cxx. The functions that have been changed are generally those that: * already take a string of determined length, so that using std::u16string_view, which is always constructed with a determined length, is no pessimization (e.g., there are operator == overloads taking plain pointers, which do not need to determine the string length upfront); * could not benefit from the fact that the passed-in argument is an OUString (e.g., the corresponding operator = overload can reuse the passed-in OUString's rtl_uString pData member); * do not run into overload resolution ambiguity issues, like the comparison operators would do. One inconsistency that showed up is that while the original replaceAll(OUString const &, OUString const &, sal_Int32 fromIndex = 0) overload takes an optional third fromIndex argument, the existing replaceAll overloads taking OUStringLiteral and literal char16_t const[N] arguments did not. Fixing that required a new (LIBO_INTERNAL_ONLY) rtl_uString_newReplaceAllFromIndexUtf16LUtf16L (with test code in sal/qa/rtl/strings/test_strings_replace.cxx). Another issue was posed by test code in sal/qa/rtl/strings/test_oustring_stringliterals.cxx that used the RTL_STRING_UNITTEST-only OUString(Except*CharArrayDetector) ctors to verify that certain function calls should not compile (and would compile under RTL_STRING_UNITTEST by taking those Except*CharArrayDetector converted to OUString as arguments). Those problematic "should fail to compile" tests have been converted into a new CompilerTest_sal_rtl_oustring. Change-Id: Id72e8c4cc338258cadad00ddc6ea5b9da2e1f780 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102020 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-02xmlsecurity: avoid saying OK when the signature is partialMiklos Vajna
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/+/101926 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-02Remove some unused includesMiklos Vajna
Change-Id: I90d4e3db3eefa41f8492cfe23c5088ea93134afc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101890 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-01Fix typoAndrea Gelmini
Change-Id: I03dc9ad3ad496524efbbb2f1a48f76fb95d1bfc5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101781 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-31xmlsecurity: fix infobar vs signature dialog inconsistencyMiklos Vajna
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". Change-Id: I698190aa77702000b11d635bd038d9c9a91614ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101712 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-28Change OUStringLiteral from char[] to char16_t[]Stephan Bergmann
This is a prerequisite for making conversion from OUStringLiteral to OUString more efficient at least for C++20 (by replacing its internals with a constexpr- generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount, conditionally for C++20 for now). For a configure-wise bare-bones build on Linux, size reported by `du -bs instdir` grew by 118792 bytes from 1155636636 to 1155755428. In most places just a u"..." string literal prefix had to be added. In some places char const a[] = "..."; variables have been changed to char16_t, and a few places required even further changes to code (which prompted the addition of include/o3tl/string_view.hxx helper function o3tl::equalsIgnoreAsciiCase and the additional OUString::createFromAscii overload). For all uses of macros expanding to string literals, the relevant uses have been rewritten as u"" MACRO instead of changing the macro definitions. It should be possible to change at least some of those macro definitions (and drop the u"" from their call sites) in follow-up commits. Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-03tdf#42949 Fix IWYU warnings in include/[t-x]*/*hxxGabor Kelemen
Recheck after 7-0 branchoff Also drop the now unused file include/vcl/field.hxx Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I9e54c82f50d1e02a0f99858939cac999fc66f7de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99261 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-08-02loplugin:flatten in xmlsecurityNoel Grandin
Change-Id: Ic9e410c77a04edbd58485d4177da22e17efa8720 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99964 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-24xmlsecurity: detect unsigned incremental update between signaturesMiklos Vajna
Change-Id: I269ed858852ee7d1275adf340c8cc1565fc30693 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99361 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-07-20compact namespace declNoel Grandin
used git grep -lw namespace | xargs perl -i -p0e 's/(\w+)\s*.\{.\s*namespace\s*(\w+)/\1::\2/smg;' to do the initial replace, then compiled and fixed. Change-Id: If69904d75940c851aeffab0e78c4ba02cc968d44 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98526 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-10replace usage of blacklist with denylistThorsten Behrens
.. and a few cases of instead doing blacklist->excludelist where that made more sense. Background and motivation: https://tools.ietf.org/html/draft-knodel-terminology-02 [API CHANGE] officecfg::Office::Canvas::DeviceBlacklist -> DeviceDenylist [API CHANGE] officecfg::Office::Canvas::BlacklistCurrentDevice -> DenylistCurrentDevice [API CHANGE] officecfg::Office::Common::Misc::OpenCLBlackList -> OpenCLDenyList Change-Id: Ia35e25496bf0cc0692d5de4cb66bfc232d3a869e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98180 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-03[API CHANGE] Move NSS profile handling into NSS serviceJan-Marek Glogowski
While developing the patchset for tdf#127909, I broke the certificate path dialog, because I wasn't aware, that the NSSInitializer service has to use the same logic to auto- select the users profile, then the dialog. So currently you have to keep the complex service and dialog auto-select logic in sync. To prevent this error, this moves all the profile auto-selection and enumeration into the NSSInitializer service. What I also stumbled over is the particular lifecycle of the NSS library initialization in the NSS service. This is just done, when the first user calls some crypto function. As a result it's actually possible to change the path setting without restarting LibreOffice. But since the NSS deninitialization is run as an atexit handler, this setting can't be changed after the init. What is currently missing is any indication inside the dialog of the currently active NSS setting in comparison to any later user selection, if the user doesn't restart LibreOffice as requested. Change-Id: I886962777958c363abeb0ec91fc8a35cbd39eb98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97668 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-07-01Remove some unused includesMiklos Vajna
Change-Id: I44c9ad2511d484e3c7fb1c33f25fcb343eabd232 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97548 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-06-26Upcoming improved loplugin:elidestringvar: xmlsecurityStephan Bergmann
Change-Id: I1490e79489a98dd97ec31d6b52b4f05a1411de79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97212 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-25sd signature line: pass the model down to xmlsecurityMiklos Vajna
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. Change-Id: Ie81996b8f1e8851975b27c43a53f9d23e316004e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97116 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-06-25sd signature line: place shape on the correct pageMiklos Vajna
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. Change-Id: I63decba98774151e9634ea924c2fed0f7814cb28 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97045 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-06-16sd signature line: access the pdf shape from the appearance writerMiklos Vajna
PDFDocument::WriteAppearanceObject() is where we can turn the pdf data (containing a single shape only) into a form XObject, later. Change-Id: Id042c95af4a867d3997d6f7742a18659b8925c12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96455 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-06-16sd signature line: export shape with signature to PDFMiklos Vajna
So that later this can be used when writing the appearance object of the pdf signature. Change-Id: I98517b88723de8ffdc982d4eaae7225289603f1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96451 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-06-05have just one way to set expander imageCaolán McNamara
Change-Id: Ic07709a864620c6146616c8e0a1417343c0937de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95590 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-05-19oox, svx, sw, xmlsecurity: clang-format these filesMiklos Vajna
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
2020-05-18officecfg,unotools,cui: add ODF 1.2 Extended / ODF 1.3 versionsMichael Stahl
... 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>
2020-05-13expand out some namespace aliasesNoel Grandin
Change-Id: I5fdb554a1b116824843f35645bc1cea3ca91e0f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94093 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-10compact namespace in xmlhelp..xmlsecurityNoel Grandin
Change-Id: I54f0a47a4b7a1f85481fd1e643ac55459d0383ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93907 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-29Remove unnecessary if blockSamuel Mehrbrodt
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>
2020-04-29tdf#131733 Show only CN part of X.509 subject infoGabor Kelemen
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>
2020-04-27Missing includes on Windows with --disable-pchMike Kaganski
... since b512ce255f46d90e682634e4dd17e146af7f9080. Yes, MSVC also produces an error if the completeness requirements are not met. Change-Id: I0ad573ef1d14a383eed3a8f83aa932657c22ae20 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92963 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-04-27Make upcasting css::uno::Reference ctor require complete typesStephan Bergmann
The main reason for the "home-grown" UpCast introduced with 904b3d1fceee5827076758ed2a81f80cb73493ca "Up-cast conversion constructor for css::uno::Reference" in 2013 was probably that we could not yet rely on C++11 std::is_base_of back then. A (welcome) side effect was that the derived class could be incomplete. However, specializations of UpCast relying on whether or not T2 is incomplete are obviously an ODR violation if the type is incomplete in some TUs and complete (and derived from T1) in others. And even if UpCast had internal linkage, it would still be brittle that its behavior depends on the completeness of T2 at the point of the template's instantiation, and not necessarily at the point of use. That means we should better base that ctor on std::is_base_of (which we can do now since 39a1edd6fec902ef378acce8af42c4d7fba280d0 "Make css::uno::Reference upcast ctor LIBO_INTERNAL_ONLY"), which causes a compilation error at least on Clang and GCC if the completeness requirements are not met. This change fixes all the cases where types need to be complete now, plus any resulting loplugin:referencecasting warnings ("the source reference is already a subtype of the destination reference"). Change-Id: Ieb9e3552e90adbf2c5a5af933dcb872e20661a2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92950 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-07new loplugin:unusedvariableplusNoel Grandin
a particularly aggressive checker, which is why it is off by default Change-Id: Id5a0faa50b3ecc75e01f4aedc6579c5209e585da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91643 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-02xmlsec-wrapper.h must be included before any xmlsec headerMike Kaganski
This fixes structs size mismatch between xmlsec and its users because of XMLSEC_NO_SIZE_T not yet defined at the time of their definition. See https://lists.freedesktop.org/archives/libreoffice/2020-April/084800.html Change-Id: I8de9a012f849d9a5a84f5ce580484b66192d1e06 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91531 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-04-01Drop useless initialization immediately before reassignmentMike Kaganski
Change-Id: Id3d05de26ac9078a316de49ea2a5f6af26876107 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91507 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-03-25Remove unused using declarations in oox...xmlsecurityGabor Kelemen
Found by: run-clang-tidy-10 -checks=-*,misc-unused-using-decls Change-Id: I3e95791e223ef01e140a6217e29a9efae428a784 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90876 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
generated by cgit (git 2.34.1) at 2025-01-25 08:44:42 +0000