summaryrefslogtreecommitdiff
path: root/xmlsecurity/qa
AgeCommit message (Collapse)Author
2022-09-29split utl::TempFile into fast and named variantsNoel Grandin
which makes it easier to know what each variant requires to stay on it's happy path Change-Id: I3275a2543573367714bc78092e882f6535507285 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140469 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-09-29use more string_view in xmlsecurityNoel Grandin
Change-Id: I245961d0116a7a72f8506cfc0b009990e35c6796 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140710 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-07-29Verify signing certificate cryptographically before use in testsMike Kaganski
Documents signed using an invalid (e.g., not having a trusted root) certificate give signatures that obviously can't pass validity tests. Change-Id: Id4b097516e06c548ea42cad65d76bbd8a6853cc4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137620 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-07-20tdf#127236 vcl: fix missing encryption of PDF images during exportMiklos Vajna
Regression from commit 78e25558e86188314b9b72048b8ddca18697cb86 (tdf#106059 PDF export: create a reference XObject for JPG images with PDF data, 2017-02-23), once a PDF image was inserted to a document, an encrypted PDF export lost those images. The reason for this is that we started to preserve PDF images as vector data with the above commit, but this means we copied over PDF objects from PDF images to the export result as-is, so encryption was not performed for them. Fix this by separating the write of the PDF object headers, stream content and object footer and then calling checkAndEnableStreamEncryption() / disableStreamEncryption() for each object, even if it's not something our PDF export created but comes from a PDF image. Note that when existing PDF files are signed, PDF objects are also copied into a vcl::filter::PDFDocument, but such PDF images are never encrypted, so it's fine to have stub implementations in vcl::filter::PDFDocument. Change-Id: I2f74b9f51cd35b4319221532ca890e197bab9cf3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137242 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-05-05tdf#145312: xmlsecurity_pdfsigning: Add unittestXisco Fauli
Change-Id: I12d6af46d13daa06eab98cdf81c82c6f5f41b5c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133881 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2022-05-03Just use Any ctor instead of makeAny in xmlsecurityStephan Bergmann
Change-Id: Ic2e9189d116b03122d24a477d9396ca3d49a0a25 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133698 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-01Fix the test failing when invalid certificate is in cert storeMike Kaganski
testSigningMultipleTimes_ODT was failing for me locally because of an expired certificate present in my store. Change-Id: Ie3dfb9ee1a110259ba747a03fc28c205df2eea91 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130743 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-11-24Rename o3tl::underlyingEnumValue to o3tl::to_underlying to match C++23Mike Kaganski
Change-Id: I1597a8e77199445bf377dbe54adc3134bb04fd51 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125748 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-11-02xmlsec: fix OOXML signing with multiple certs, extend the testTomaž Vajngerl
Signing OOXML with 3 or more times didn't work as other ids ("idPackageObject", "idOfficeObject", ...) were not uniqe. This change makes those ids unique by appending the signature id. The signature ID is now generated for OOXML too, while previously it was a hardcoded string ("idPackageSignature"). The test for signing multiple OOXML was written before, but didn't catch the issues because it didn't assert the status of the document after loading it again. This is which is now fixed (and also added changed for the ODF test case). Change-Id: Ifa20ea17498b117a4c57f6eddf82f8e83bc640bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124571 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-10-28xmlsec: signing the document fails the 3rd time (invalid signature)Tomaž Vajngerl
Signing the document 3 or more times produces an invalid signature. The cause of this is that xmlsec is confused because we have 3 signatures, which all have the same SignedProperties with the ID "idSignedProperties", but it expect them to be unique. This issue is fixed by making the ID unique with adding the ID of the Signature to the SignedProperties ID, so this makes them unique inside the same Signature. Also UnsignedProperties have a unique ID usign the same approach, but they aren't referenced - luckily. Change-Id: I53c7249a82fc0623586548db9fa25bdc0e7c4101 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124278 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-10-27xmlsecurity: some Distinguished Names are less equal than othersMichael Stahl
It turns out that the 2 backends NSS and MS CryptoAPI generate different string representations of the same Distinguished Name in at least one corner case, when a value contains a quote " U+0022. The CryptoAPI function to generate the strings is: CertNameToStr(..., CERT_X500_NAME_STR | CERT_NAME_STR_REVERSE_FLAG, ...) This is documented on MSDN: https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certnametostra#CERT_X500_NAME_STR NSS appears to implement RFC 1485, at least that's what the internal function is named after, or perhaps one of its several successor RFCs (not clear currently if there's a relevant difference). This is now causing trouble if a certificate with such a DN is used in a signature, created on WNT but then verified on another platform, because commit 5af5ea893bcb8a8eb472ac11133da10e5a604e66 introduced consistency checks that compare the DNs that occur as strings in META-INF/documentsignatures.xml: xmlsecurity/source/helper/xmlsignaturehelper.cxx:672: X509Data cannot be parsed The reason is that in XSecController::setX509Data() the value read from the X509IssuerSerial element (a string generated by CryptoAPI) doesn't match the value generated by NSS from the certificate parsed from the X509Certificate element, so these are erroneously interpreted as 2 distinct certificates. Try to make the EqualDistinguishedNames() more flexible so that it can try also a converted variant of the DN. (libxmlsec's NSS backend also complains that it cannot parse the DN: x509vfy.c:607: xmlSecNssX509NameRead() '' '' 12 'invalid data for 'char': actual=34 and expected comma ','' but it manages to validate the signature despite this.) Change-Id: I4f72900738d1f5313146bbda7320a8f44319ebc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124287 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-10-21Fix commentTor Lillqvist
Change-Id: Ifd1068066c8711a1fa96ff4ede1fa0017a221617
2021-10-20Run testODFX509CertificateChain first because otherwise it fails on my MacTor Lillqvist
Sure, it would be better to figure out why it fails. Change-Id: I4c9e8aa0a9a3cd421de08ec9c9ea2dcb1a242ab1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123875 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-10-19xmlsecurity: fix test failing because NSS policy forbids SHA1Michael Stahl
With Fedora's nss-3.71.0-1.fc34.x86_64 there is the problem that 8 tests including testODFGood in CppunitTest/xmlsecurity_signing fail because the crypto policy disallows SHA1 for signatures. Apparently this particular policy bit was added in NSS 3.59: https://bugzilla.mozilla.org/show_bug.cgi?id=1670835 For signatures, maybe it's not a good idea to override system policy for product builds, so do it locally in the tests, at least for now. Another option would be to set NSS_HASH_ALG_SUPPORT environmental variable to something like "+SHA-1". If similar problems turn up for encrypted documents in the future, that should be fixed in product builds too of course, as encrypted documents must always be decryptable. Change-Id: I4f634cf5da1707fb628e63cd0cdafebdf4fc903f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123678 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-10-18xmlsecurity: fix new tests on WNTMichael Stahl
Tests added in commit 40d70d427edddb589eda64fafc2e56536953d274 don't actually run on WNT but that wasn't obvious because commit 149df1fec6472e30582162e17e04c75aee91d26a prevented running them in Jenkins on master, they failed only in the libreoffice-7-1 backport. xmlsecurity/qa/unit/signing/signing.cxx(631) : error : Assertion Test name: testODFDoubleX509Certificate::TestBody assertion failed - Expression: (nActual == SignatureState::NOTVALIDATED || nActual == SignatureState::OK) - 2 This is an oddity where NSS claims the signature in the document is valid but CryptoAPI claims it is invalid; the hashes passed into the validation functions are the same. Just allow BROKEN as an additional result value on WNT. xmlsecurity/qa/unit/signing/signing.cxx(550) : error : Assertion Test name: testODFX509CertificateChain::TestBody equality assertion failed - Expected: 0 - Actual : 1 The problem here is that with NSS the tests use a custom NSS database in test/signing-keys so we need to make these certificates available for CryptoAPI too. The following one-liner converts the NSS database to a PKCS#7 that can be loaded by CrytpAPI: > openssl crl2pkcs7 -nocrl -certfile <(certutil -d sql:test/signing-keys -L | awk '/^[^ ].*,[^ ]*,/ { printf "%s", $1; for (i = 2; i < NF; i++) { printf " %s", $i; } printf "\n"; }' | while read name; do certutil -L -d sql:test/signing-keys -a -n "${name}" ; done) > test/signing-keys/test.p7b Then one might naively assume that something like this would allow these certificates to be added temporarily as trusted CAs: + HCERTSTORE hRoot = CertOpenSystemStoreW( 0, L"Root" ) ; + HCERTSTORE const hExtra = CertOpenStore( + CERT_STORE_PROV_FILENAME_A, + PKCS_7_ASN_ENCODING | X509_ASN_ENCODING, + NULL, + CERT_STORE_OPEN_EXISTING_FLAG | CERT_STORE_READONLY_FLAG, + path); + if (hExtra != NULL && hRoot != NULL) + { + BOOL ret = CertAddStoreToCollection( + hRoot, + hExtra, + CERT_PHYSICAL_STORE_ADD_ENABLE_FLAG, + 0); + SAL_DEBUG("XXX hExtra done " << ret); + } There is no error from this, but it doesn't work. Instead, check if CertGetCertificateChain() sets the CERT_TRUST_IS_UNTRUSTED_ROOT flag and then look up the certificate manually in the extra PKCS#7 store. Change-Id: Ic9865e0b5783211c2128ce0327c4583b7784ff62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123667 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-10-17Simplify Sequences in xmlsecurityJulien Nabet
Change-Id: I749e19f786ad006dffcd65dd1ee60e57c428f57b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123717 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-15Remove non-const Sequence::begin()/end() in internal codeMike Kaganski
... to avoid hidden cost of multiple COW checks, because they call getArray() internally. This obsoletes [loplugin:sequenceloop]. Also rename toNonConstRange to asNonConstRange, to reflect that the result is a view of the sequence, not an independent object. TODO: also drop non-const operator[], but introduce operator[] in SequenceRange. Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-14Avoid COW overhead using css::uno::SequenceMike Kaganski
The scenarios are: 1. Calling sequence's begin() and end() in pairs to pass to algorithms (both calls use getArray(), which does the COW checks) 2. In addition to #1, calling end() again when checking result of find algorithms, and/or begin() to calculate result's distance 3. Using non-const sequences in range-based for loops, which internally do #1 4. Assigning sequence to another sequence variable, and then modifying one of them In many cases, the sequences could be made const, or treated as const for the purposes of the algorithms (using std::as_const, std::cbegin, and std::cend). Where algorithm modifies the sequence, it was changed to only call getArray() once. For that, css::uno::toNonConstRange was introduced, which returns a struct (sublclass of std::pair) with two iterators [begin, end], that are calculated using one call to begin() and one call to getLength(). To handle #4, css::uno::Sequence::swap was introduced, that swaps the internal pointer to uno_Sequence. So when a local Sequence variable should be assigned to another variable, and the latter will be modified further, it's now possible to use swap instead, so the two sequences are kept independent. The modified places were found by temporarily removing non-const end(). Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-12xmlsecurity: add tests for multiple X509Data/X509CertificateMichael Stahl
Change-Id: If50ae8156f81c1053aa8fbfc3148da64bb8e1442 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111666 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins
2021-10-12xmlsecurity: add test for timestampsMichael Stahl
Change-Id: I6ce64ca7c59639684779144ed0ed8d36c4aca32b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111665 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-08-20Make some scripts more portableIlmari Lauhakangas
Change-Id: Ia89059eea51ca396a7c74143625ac9a6706de198 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120773 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2021-05-14Improve loplugin:stringviewStephan Bergmann
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for operator call arguments. (The "rather than copy, pass subView()" diagnostic is already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly for operator call arguments.) (And many call sites don't even require an explicit [u16]string_view, esp. with the recent ad48b2b02f83eed41fb1eb8d16de7e804156fcf1 "Optimized OString operator += overloads". Just some test code in sal/qa/ that explicitly tests the O[U]String functionality had to be excluded.) Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-03-12explicitly assert that xSignatureInfo shouldn't be emptyCaolán McNamara
Change-Id: I4cd1be8b4c0b7ecb727e6a997679a9b74c03bc15 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112362 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-03-12Drop some unused includesMiklos Vajna
Change-Id: Ic79d81387867f028eb8dc9553fb87f5961d6c771 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112364 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-03-05CppunitTest_xmlsecurity_signing: run all tests in the disable-pdfium caseMiklos Vajna
Return early in case pdfium is not available, to avoid the ifdef forest. Change-Id: Ifdf71eb01437e4257679c9be7a25de9a3133a660 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111978 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-03-05tdf#139734 Remove redundant asserts after functions loadFromDesktop and loadMoaz
MacrosTest::loadFromDesktop itself asserts on its return value. Thus, the additional checks in unit tests are redundant, and only create noise unrelated to the tested functionality. SwModelTestBase::load calls SwModelTestBase::loadURL which calls loadFromDesktop from within. Change-Id: I30061bbc6e13e05f0cfbf17a7910926070b996f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111547 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-03-04CppunitTest_xmlsecurity_pdfsigning: run all tests in the disable-pdfium caseMiklos Vajna
Return early in case pdfium is not available, to avoid the ifdef forest. Change-Id: Iea6feb1492a68eb7ea718e4bee05f1e3bfc98e89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111936 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-02-26pdfium: don't build PDFiumLibrary when PDFium is disabledMiklos Vajna
Rather provide a stub implementation of PDFiumLibrary::get(), so other code can call it unconditionally. This is meant to allow removing the 10 stub functions in VectorGraphicSearch later. Also fix up CppunitTest_xmlsecurity_signing to pass in the disable-pdfium case by avoiding the known-problematic checks. Change-Id: I748fcc5c623c5ce937bd2980bfdfaadbdf6cedf7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111564 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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-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-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-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-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-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-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-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-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-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-13Remove some unused includesMiklos Vajna
Change-Id: Iea6b931b1f2328886354f70ad81a3e07367db717 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100669 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-08-08Remove dead codeStephan Bergmann
mxComponent is known to be null at the start of a test function Change-Id: Ifb3b7dd33769ef71d980fb110eab2dceb03bc52c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100370 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-08Database document apparently needs to be closed before it is disposedStephan Bergmann
Otherwise, if a test like testPreserveMacroTemplateSignature10::TestBody from xmlsecurity/qa/unit/signing/signing.cxx happens to be executed after testPreserveMacroSignatureODB::TestBody from xmlsecurity/qa/unit/signing/signing2.cxx during CppunitTest_xmlsecurity_signing, it would SIGABRT with something like > warn:sfx.view:1935717:1935717:sfx2/source/view/frmload.cxx:489: DBG_UNHANDLED_EXCEPTION in static void (anonymous namespace)::SfxFrameLoader_Impl::impl_handleCaughtError_nothrow(const com::sun::star::uno::Any &, const ::comphelper::NamedValueCollection &) exception: com.sun.star.lang.DisposedException message: Frame disposed /home/sbergman/lo/core/framework/source/services/frame.cxx:362 > warn:legacy.osl:1935717:1935717:vcl/source/window/window.cxx:273: Window ( 19SfxFrameWindow_Impl()) with live children destroyed: 23SfxFrameViewWindow_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() > Window ( 19SfxFrameWindow_Impl()) with live children destroyed: 23SfxFrameViewWindow_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() at > #7 0x00007ff59b2599e9 in SalAbort(rtl::OUString const&, bool) (rErrorText="Window ( 19SfxFrameWindow_Impl()) with live children destroyed: 23SfxFrameViewWindow_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow("..., bDumpCore=true) at vcl/source/app/salplug.cxx:303 > #8 0x00007ff59b08c751 in Application::Abort(rtl::OUString const&) (rErrorText="Window ( 19SfxFrameWindow_Impl()) with live children destroyed: 23SfxFrameViewWindow_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow("...) at vcl/source/app/svapp.cxx:281 > #9 0x00007ff59a846f98 in vcl::Window::dispose() (this=0x4ea35d0) at vcl/source/window/window.cxx:274 > #10 0x00007ff5954ff853 in SfxFrameWindow_Impl::dispose() (this=0x4ea35d0) at sfx2/source/view/frame2.cxx:82 > #11 0x00007ff59aad5161 in VclReferenceBase::disposeOnce() (this=0x4ea3818) at vcl/source/outdev/vclreferencebase.cxx:38 > #12 0x00007ff591c3815b in VclPtr<OutputDevice>::disposeAndClear() (this=0x7ffd92f67810) at include/vcl/vclptr.hxx:206 > #13 0x00007ff591cbaeb8 in VCLXWindow::dispose() (this=0x52fb4c0) at toolkit/source/awt/vclxwindow.cxx:920 > #14 0x00007ff59300e147 in (anonymous namespace)::XFrameImpl::setComponent(com::sun::star::uno::Reference<com::sun::star::awt::XWindow> const&, com::sun::star::uno::Reference<com::sun::star::frame::XController> const&) (this=0x4f02260, xComponentWindow=empty uno::Reference, xController=empty uno::Reference) at framework/source/services/frame.cxx:1514 > #15 0x00007ff5930104ee in (anonymous namespace)::XFrameImpl::close(unsigned char) (this=0x4f02260, bDeliverOwnership=1 '\001') at framework/source/services/frame.cxx:1692 > #16 0x00007ff593016633 in (anonymous namespace)::XFrameImpl::implts_checkSuicide() (this=0x4f02260) at framework/source/services/frame.cxx:3189 > #17 0x00007ff59300ffb4 in (anonymous namespace)::XFrameImpl::removeActionLock() (this=0x4f02260) at framework/source/services/frame.cxx:2683 > #18 0x00007ff592fa892f in framework::ActionLockGuard::freeResource() (this=0x7ffd92f68bd0) at framework/source/inc/loadenv/actionlockguard.hxx:123 > #19 0x00007ff592f9e2de in framework::LoadEnv::impl_reactForLoadingState() (this=0x7ffd92f68ac8) at framework/source/loadenv/loadenv.cxx:1637 > #20 0x00007ff592f9d9fc in framework::LoadEnv::impl_setResult(bool) (this=0x7ffd92f68ac8, bResult=false) at framework/source/loadenv/loadenv.cxx:515 > #21 0x00007ff592f9d851 in framework::LoadEnv::impl_loadContent() (this=0x7ffd92f68ac8) at framework/source/loadenv/loadenv.cxx:1160 > #22 0x00007ff592f9a502 in framework::LoadEnv::start() (this=0x7ffd92f68ac8) at framework/source/loadenv/loadenv.cxx:395 > #23 0x00007ff592f98261 in framework::LoadEnv::startLoading(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&, rtl::OUString const&, int, LoadEnvFeatures) (this=0x7ffd92f68ac8, sURL="file:///xmlsecurity/qa/unit/signing/data/tdf42316.ott", lMediaDescriptor=uno::Sequence of length 2 = {...}, xBaseFrame=uno::Reference to (class framework::Desktop *) 0x18b3c48, sTarget="_default", nSearchFlags=0, eFeature=LoadEnvFeatures::NONE) at framework/source/loadenv/loadenv.cxx:300 > #24 0x00007ff592f96bdc in framework::LoadEnv::loadComponentFromURL(com::sun::star::uno::Reference<com::sun::star::frame::XComponentLoader> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (xLoader=uno::Reference to (class framework::Desktop *) 0x18b3c58, xContext=uno::Reference to (class cppu::(anonymous namespace)::ComponentContext *) 0xa6aeb0, sURL="file:///xmlsecurity/qa/unit/signing/data/tdf42316.ott", sTarget="_default", nSearchFlags=0, lArgs=uno::Sequence of length 2 = {...}) at framework/source/loadenv/loadenv.cxx:169 > #25 0x00007ff592ff8ce2 in framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x18b3be0, sURL="file:///xmlsecurity/qa/unit/signing/data/tdf42316.ott", sTargetFrameName="_default", nSearchFlags=0, lArguments=uno::Sequence of length 2 = {...}) at framework/source/services/desktop.cxx:593 > #26 0x00007ff592ff8da5 in non-virtual thunk to framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () at workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/lang/XComponent.hpp:136 > #27 0x00007ff593d7bb28 in unotest::MacrosTest::loadFromDesktop(rtl::OUString const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x18a6d80, rURL="file:///xmlsecurity/qa/unit/signing/data/tdf42316.ott", rDocService="", rExtraArgs=uno::Sequence of length 1 = {...}) at unotest/source/cpp/macros_test.cxx:61 > #28 0x00007ff5956b132d in testPreserveMacroTemplateSignature10::TestBody() (this=0x18a6d30) at xmlsecurity/qa/unit/signing/signing.cxx:1243 Change-Id: If2c45a8fc8d907b12f4d92c77f524d50d9e928cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100344 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-06unotest: one Resetter is enoughMiklos Vajna
It seems all 3 places derive from unotest::MacrosTest, so extract the common code there. Change-Id: I71a2474a7d6b1623f50575f9e9c43580ba076330 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100185 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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-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>
generated by cgit (git 2.34.1) at 2025-03-20 17:27:19 +0000