summaryrefslogtreecommitdiff
path: root/xmlsecurity/source/dialogs
AgeCommit message (Collapse)Author
2021-10-17Simplify vector initialization in xmlsecurityJulien Nabet
Change-Id: Ia19ffa1213d578c30f35545bcca515669e7ff7a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123710 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-11loplugin:moveparam in xmlsecurityNoel Grandin
Change-Id: I3ce77ab82529f13c5e55ea30c813f66cb5180877 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123369 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-11loplugin:moveparam in unotoolsNoel Grandin
Change-Id: Idd014c93e2e85d2ffc7a2535a9c65cffc8a9d403 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123348 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-03clang-tidy:readability-redundant-member-initNoel Grandin
Change-Id: Iede70151af052505b780c6ce708aa74d97da5c75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121545 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-05Pass context and resource string down to boost::locale separatelyNoel Grandin
because this is often on a hot path, and we can avoid the splitting and joining of strings like this. Change-Id: Ia36047209368ca53431178c2e8723a18cfe8260a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119220 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-26use officecfg for security optionsNoel Grandin
Change-Id: I9d91fd5b260b82e05aac6567143386742953ecf6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119486 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-21bundle the FolderPicker instantiations behind a single callCaolán McNamara
in prep to add parent support Change-Id: I2aa4b9343f895ae866f600dd3260b7fdc4e1efec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117579 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-05-21add Toggleable as a separate thing to a ButtonCaolán McNamara
and inherit ToggleButton from both it and Button Change-Id: If0e500aca8d0ffa087cb5e2bfc1786372fbff4eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115921 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-05-17gtk4: reenable buttonCaolán McNamara
rename label_line_wrap to label_wrap while I'm at it Change-Id: I3964c4b40d86fb6ef1fd3733088ffd80e57415ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115714 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-05-12unused include lineCaolán McNamara
Change-Id: I6a41cfa184a653f1b84cf6f33c391ccd531ffc2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115494 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-03-03xmlsecurity: avoid exception in DigitalSignaturesDialog::getCertificate()Michael Stahl
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. Change-Id: I7f382165657f50723ac65a60309567e5b6c5ae1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111664 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-03-03xmlsecurity: improve handling of multiple certificates per X509DataMichael Stahl
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. Change-Id: I9633a980b0c18d58dfce24fc59396a833498a77d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111500 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-03-03xmlsecurity: improve handling of multiple X509Data elementsMichael Stahl
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. Change-Id: I5254aa393f8e7172da59709923e4bbcd625ec713 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111254 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
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-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-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-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-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-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-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-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-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-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-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-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-03-01cid#1459028 various checked_return warningsCaolán McNamara
and cid#1459027, cid#1459026, cid#1459025, cid#1459024, cid#1459021, cid#1459018 Change-Id: If92e7665fcf947c5daf3094b9003e85c5c51f48f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89763 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-02-12clang-analyzer-deadcode.DeadStoresNoel Grandin
Change-Id: Ifa384933569b27d0d08eb479bb95b799163ae386 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88450 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-17Fix macro security UI usability problemsJan-Marek Glogowski
* 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>
2019-10-31Fix StringAdd::isCompileTimeConstantStephan Bergmann
...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-06Related: tdf#127935 set default activate handler to toggle row expansionCaolán McNamara
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-09-28loplugin:constmethod in xmlsecurityNoel Grandin
Change-Id: I7892b4819fd7491882e6ca995bf2ce5c65230609 Reviewed-on: https://gerrit.libreoffice.org/79791 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-20tdf#116862 do not encrypt to self when encryption key is not setFranklin Weng
When "always encrypt to self" is checked but no encryption key is set, encrypting a file with GPG key would cause error. So check if msPreferredKey is empty or not before comparing with sIssuer. Change-Id: I4d95f0b436cb1fafad1d57d50330fd2080902b69 Reviewed-on: https://gerrit.libreoffice.org/77665 Tested-by: Jenkins Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
2019-08-16use more TOOLS_WARN_EXCEPTIONNoel Grandin
Change-Id: Ic21ea11ff106e0732bb8fa600ef39a549d7bda86 Reviewed-on: https://gerrit.libreoffice.org/77569 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-16new loplugin:sequenceloopNoel Grandin
look for places we should be using std::as_const on for-range loops over uno::Sequence, to avoid triggering a copy Change-Id: I7efb641bf09d37c87946f03428ee4eec90298c8a Reviewed-on: https://gerrit.libreoffice.org/77441 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-14Simplify OUString array initializationMike Kaganski
Change-Id: I54945ed1ea2292ecc02ff988c4ecf310a9c4b87a Reviewed-on: https://gerrit.libreoffice.org/77451 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-08-14Don't hardcode "C:\\Program Files (x86)" path on WindowsMike Kaganski
It might be simple "Program Files" on 32-bit system; or localized (see https://www.samlogic.net/articles/program-files-folder-different-languages.htm), or on a different drive (if system isn't on C:), etc. Change-Id: Id0f28b4c4920fcda53a58fbff9f42bcfde6668f6 Reviewed-on: https://gerrit.libreoffice.org/77448 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-08-13tdf#116085 add more Gpg4Win binary locationsThorsten Behrens
Seems Gpg4Win recently grew a few more variants where to put stuff. Look there, too. Change-Id: Ifa09db11665671f518a6a66480c1a71fd619d8cd Reviewed-on: https://gerrit.libreoffice.org/77341 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-07-31Fix typosAndrea Gelmini
Change-Id: I69e5c6d82fddd1da1e414e7764f3a5d90351a43d Reviewed-on: https://gerrit.libreoffice.org/76377 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-07-21loplugin:referencecasting in xmlsecurityNoel Grandin
Change-Id: Ic3daba9e6e94516ea4d80f25f73e9e46a50edb5c Reviewed-on: https://gerrit.libreoffice.org/76035 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-16cid#1448248 Unchecked return valueCaolán McNamara
Change-Id: I3b50d3affeb0c25a12dcb2ae0d5c2216d5419249 Reviewed-on: https://gerrit.libreoffice.org/75659 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-05-15xmlsecurity: make DocumentSignatureManager members privateMiklos Vajna
Change-Id: I1262ca0dc2b2f843bdd6277415ee7967e9e59458 Reviewed-on: https://gerrit.libreoffice.org/72320 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-05-10an is used before a vowel soundCaolán McNamara
not before vowels with a consonant sound so its a url not an url Change-Id: Ic27ff3bee67469284d460c31ced6f63cb3633db2 Reviewed-on: https://gerrit.libreoffice.org/72062 Reviewed-by: Jens Carl <j.carl43@gmx.de> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-05-09Simplify Sequence iterations in xmlscript, xmlsecurityArkadiy Illarionov
Use range-based loops or replace with comphelper or STL functions Change-Id: I3d63811caf80c87a9d560087e1f0d933ebcc0d55 Reviewed-on: https://gerrit.libreoffice.org/72040 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-05-09tdf#42949 Fix IWYU warnings in xmlsecurity/*cxxGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I89c77656ea4021cb16bd122cb1dd1cd803390c3d Reviewed-on: https://gerrit.libreoffice.org/71765 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-05-02Use hasElements to check Sequence emptiness in [v-x]*Arkadiy Illarionov
Similar to clang-tidy readability-container-size-empty Change-Id: I71e7af4ac3043d8d40922e99f8a4798f0993294c Reviewed-on: https://gerrit.libreoffice.org/71603 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-29tdf#42949 Fix IWYU warnings in xmlsecurity/*hxxGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. All hxx cleaned except the ones in xmlsecurity/source/xmlsec/mscrypt Change-Id: I651f53c9d339208b3132f9078a5c3829ff9c5dc8 Reviewed-on: https://gerrit.libreoffice.org/71448 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-04-15loplugin:sequentialassign in writerfilter..xmlsecurityNoel Grandin
Change-Id: I41028c704eca08b71746c3c87e38926b95449775 Reviewed-on: https://gerrit.libreoffice.org/70735 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-03-16weld SwEditRegionDlgCaolán McNamara
Change-Id: I6aacd013a344caa731841ff4f015017ba16c4aca Reviewed-on: https://gerrit.libreoffice.org/69325 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit (git 2.34.1) at 2024-06-28 21:30:43 +0000