summaryrefslogtreecommitdiff
path: root/xmlsecurity
AgeCommit message (Collapse)Author
2021-01-10fix coverity parse errorsCaolán McNamara
Change-Id: I4884bfb67a061b865e8cf38b2fea6de0cb1bc3d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109057 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-29loplugin:stringviewparam: operator +Stephan Bergmann
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-26New loplugin:stringliteralvarStephan Bergmann
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for details. (Turned some affected variables in included files into inline variables, to avoid GCC warnings about unused variables.) Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-22drop deprecated GtkAlignment, move left/top-padding into child margin-start/topCaolán McNamara
for xmlsecurity, this uses the standard margin-top of 6, removing the additional 6 used in this one dialog Change-Id: Iac729122cc6e28fb17db3866bc7d8759861d3344 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108200 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-22replace deprecated xpad/ypadCaolán McNamara
drop entirely suspicious xpad/ypad which are probably accidental Change-Id: Ie80d93502359373e38cc61f63cd5bec962f5d193 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108115 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-22replace margin-left with margin-start and margin-right with margin-endCaolán McNamara
Change-Id: Iee3cc8c22b393ca420d0ed68673c61fe7ef240ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108113 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-21disable some more tests for non-default-dpiNoel Grandin
Change-Id: If5aecfb01685e2953fafdfc190054a28b9315bf0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108054 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-19don't mention VclBuilder in the dialog tests docsCaolán McNamara
Change-Id: Id18a25e3d3310342887757fe417769f4213b8a3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107981 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-19make *String(string_view) constructors explicitNoel Grandin
to make it more obvious when we are constructing heap OUStrings code and potentially inadvertently throwing away performance. And fix a handful of places so revealed. Change-Id: I0cf390f78026f8a670aaab53424cd31510633051 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107923 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-15update pchesCaolán McNamara
Change-Id: I280dea8fe5f346a5555f4bf479896877579d63e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107748 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann
...for LIBO_INTERNAL_ONLY. These had been missed by 1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take std::u16string_view parameters" because they did not match the multi-overload pattern that was addressed there, but they nevertheless benefit from being changed just as well (witness e.g. the various resulting changes from copy() to subView()). This showed a conversion from OStringChar to std::string_view to be missing (while the corresponding conversion form OUStringChar to std::u16string_view was already present). The improvement to loplugin:stringadd became necessary to fix > [CPT] compilerplugins/clang/test/stringadd.cxx > error: 'error' diagnostics expected but not seen: > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd] > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd] > 2 errors generated. Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-08use proper struct for trusted authorsNoel
instead of passing around a Sequence<String>, there is no need to use UNO types here. Change-Id: I1b9a1b6919f830d8ce29139b4362b979a669d505 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107396 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-07move various notebookbar widgets into vclCaolán McNamara
and we can drop their factories then Change-Id: I1e261886dd7700710ba628da4bbeeba65efa1531 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107134 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-04disable tests that don't work without pdfiumCaolán McNamara
we're probably past the end of the road on --disable-pdfium Change-Id: Id91ea6c77bbdb3ecf609a7ffd16a278eb3b17e91 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107222 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-04update pchesCaolán McNamara
Change-Id: I3e22c2000da03f6f3345353846213203993aa865 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107192 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-01OSL_FAIL.*exception -> TOOLS_WARN_EXCEPTIONNoel
Change-Id: I6800e23ead2767d245d5da71d2d40e0f8a6d7e1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106859 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-26pdfium: replace PDFiumSignature::getPointer() with typed gettersMiklos Vajna
Once reason and time has getters, no need to expose the underlying PDFium type. Change-Id: I8f6b152fddf38e76ad7c3b1897fcb2026129820f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106631 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-25loplugin:stringviewparam (clang-cl)Stephan Bergmann
Change-Id: Id93a1c48cd0cc1aa8370498ce239035fc5c01730 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106570 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-25loplugin:stringview (clang-cl)Stephan Bergmann
Change-Id: I47b44c80b2a5e3c9d84f5d7257efe17f138a1067 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106563 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-25pdfium: add sig getters: ByteRange, DocMDPPermission, Contents and SubFilterMiklos Vajna
Change-Id: Ieab577de92898568e27a879af1ca1bda170a307d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106554 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-24loplugin:stringviewparam extend to comparison operatorsNoel
which means that some call sites have to change to use unicode string literals i.e. u"foo" instead of "foo" Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-20pdfium: add a signature wrapper classMiklos Vajna
It just hides the underlying FPDF_SIGNATURE, no real member functions yet. Change-Id: I37d27c26d6f05b1f8c697a5afe682c795e5d4d1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106184 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-19tdf#123936 Formatting files in module xmlsecurity with clang-formatPhilipp Hofer
Change-Id: I25c8d1a3c706f1ba7565a5f018b9660faf63ffaf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105734 Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
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-15add <!-- n-columns=1 n-rows=1 --> before every GtkGridCaolán McNamara
for a in `git ls-files '*.ui'`; do sed -i 's/^\( *\)\(<object class="GtkGrid".*\)/\1<!-- n-columns=1 n-rows=1 -->\n\1\2/' $a; done so we get the same behavior in glade as before 3.38 in that the grid preview don't show any unoccupied grid squares replace all existing n-columns=X n-rows=Y lines because they are all wrong, except for cui/uiconfig/ui/additionsfragment.ui sw/uiconfig/swriter/ui/pageheaderpanel.ui sw/uiconfig/swriter/ui/pagefooterpanel.ui which are correct. Change-Id: I401bbe8e098c26e7f57d6a872d3b70fc1ce85a00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105846 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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-11tdf#124176 Use #pragma once in xmlsecurityTRaXIn
Change-Id: I1e27a17575963d084eb761f5a715f451db4bac62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105522 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
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-22set all .ui min require version of gtk to 3.20Caolán McNamara
and update the version mentioned in our min req in the readme.xrm follow up to commit 0c9ccc7dbf6deb4d012e0d1e6eb934e54e0f19bc Author: Caolán McNamara <caolanm@redhat.com> Date: Fri Oct 2 21:21:45 2020 +0100 raise min version of gtk to 3.20.0 Change-Id: Ibae55c97e1ee577f4b7435d124cda6a21005ad0c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104692 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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-30vcl: add PDFiumAnnotation::getObjectCount()Miklos Vajna
And use it in xmlsecurity, instead of the upstream scopers, to standardize on a single set of pdfium wrappers. Change-Id: Iec4baf34a607b23f1b9de8c4b969801c5973c1ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103636 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@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-24CppunitTest_xmlsecurity_pdfsigning: use PDFSignatureHelper for sig 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: Ifdf2905773ce26c2314683ff770419350ce74e0a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103274 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-21update pchesCaolán McNamara
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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-04TabPage no longer needs to inherit from VclBuilderContainerCaolán McNamara
Change-Id: Iaab26ade1109daf732e58a2f3741cc43243e374c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102023 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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>
generated by cgit (git 2.34.1) at 2025-02-05 16:57:29 +0000