Like file:///C:/lo/core//sw/qa/extras/rtfexport/data//tabs.rtf
Reimplement Directories::get{URL,Path}From{Src,Workdir} to check
and insert missing / remove excessive slashes as needed.
Change-Id: Ibd3657b0557bf1712c2de9ac74db0977754a2ed9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187932
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
... and reset the view options that are toggled in
testHiddenParagraphFollowFrame and testHiddenParagraphFlys.
Backporting these tests to the libreoffice-24-8 branch broke 2 unrelated
tests because of the changed view settings:
Test name: (anonymous namespace)::testHiddenSectionPageDescs::TestBody
equality assertion failed
- Expected: 532
- Actual : 798
- In <>, attribute 'height' of '/root/page[2]/body/section[1]/infos/bounds' incorrect value.
xmltesttools.cxx:203:Assertion
Test name: (anonymous namespace)::testTable0HeightRows::TestBody
equality assertion failed
- Expected: 28
- Actual : 22
- In <>, XPath '/root/page[1]/body/tab/row' number of nodes is incorrect
Change-Id: Ie58242348fecabe163e54048f3896c6d427d2608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177691
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
we can just take a "const &".
(found by running clang-tidy with the
performance-unnecessary-copy-initialization warning)
Change-Id: I20fd208c65303da78170b1ac06c638fdf3aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176267
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
The problem was that running UITest_xmlsecurity_gpg changed the files in
test/signing-keys/ ... prevent that by copying the directory in that
test, which is more complicated than initially expected.
Change-Id: Ie3be922e0b2e9dae49f9a70e35ad5270c90b4fc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171322
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
The new tests fail with:
> core/xmlsecurity/qa/unit/signing/signing2.cxx:
> 252: Assertion
> Test name: testPasswordPreserveMacroSignatureODFWholesomeLO242::TestBody
> equality assertion failed
> - Expected: 1
> - Actual : 4
This is because only the first test that runs sees the testing CA
certificates that are copied in MacrosTest::setUpNssGpg(); when the
second test runs, they have somehow vanished.
This is because apparently SQLite on MacOSX, unlike on Linux, monitors
the file descriptors of its database files, and then invalidates itself
when setUpNssGpg() via osl::File::copy() renames and unlinks the
existing database files:
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode renamed while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/cert9.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 5 (0x20)
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode unlinked while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/cert9.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 5 (0x11)
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode renamed while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/key4.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 6 (0x20)
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode unlinked while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/key4.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 6 (0x11)
Split MacrosTest::setUpNssGpg()/tearDownNssGpg() into functions
setUpX509() which only does something on the 1st invocation, and
setUpGpg()/tearDownGpg() which may be invoked per-test (they could also
be run once for the whole test suite, but not obvious how to do that);
PDF related tests don't need GPG.
Presumably this is (along with the WNT-specific problem fixed in commit
3e9a700091) the reason why most of the
tests not only accept the expected result of SignatureState::OK but also
SignatureState::NOTVALIDATED.
Change-Id: I59b85ca651cecaccfdea729ed1e645c53079c8bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162693
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The plugin in its current form is probably not intending to find these cases.
But it happened to do so on macOS with libc++, where the std::basic_string ctors
taking a final defaulted Allocator argument are instead implemented by a pair of
overloaded ctors, one taking no Allocator at all (see
671d1c6cd1 "Adapt loplugin:unnecessarygetstr to
libc++").
But these changes here are useful regardless, so lets leave it at that.
Change-Id: I2776671e2953182bdcad36432951a75f82412ebb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151410
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Often a developer debugging a failing CppUnit test wants a core dump with the
place where an uncaught exception is thrown. So if the newly introduced
CPPUNIT_PROPAGATE_EXCEPTIONS environment variable is set (to any value), disable
all the protectors that would otherwise catch such exceptions (and just report
some limited information about them).
Change-Id: I3052f71c0787583c496279a6f5b35a0299c357b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143882
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Otherwise, testSignCertificateSubjectName that has an explicit certificate
subject name requirement would fail when user has other valid certificates,
but not this one.
Change-Id: Ic3c440a8316314c922a53a51085a3e829f235f6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137593
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
When given an unprefixed path, CentOS7 system NSS 3.67 apparently
ignores the nice unit test database and creates a legacy "dbm:" one in
the same directory, which is of course empty.
This causes:
xmlsecurity/qa/unit/signing/signing.cxx:570:aaa_testODFX509CertificateChain::TestBody
equality assertion failed
- Expected: 0
- Actual : 1
The intermediate/root CA certificates are read from the signature and
added with CERT_NewTempCertificate(), which then does a lookup in the
database to find the trust flags of the certificate:
0 nssTrust_GetCERTCertTrustForCert () at pki3hack.c:610
1 fill_CERTCertificateFields () at pki3hack.c:819
2 stan_GetCERTCertificate () at pki3hack.c:926
3 STAN_GetCERTCertificate () at pki3hack.c:973
4 add_cert_to_cache () at tdcache.c:721
5 nssTrustDomain_AddCertsToCache () at tdcache.c:849
6 cert_createObject () at pkibase.c:1023
7 nssPKIObjectCollection_GetObjects () at pkibase.c:853
8 nssPKIObjectCollection_GetCertificates () at pkibase.c:1077
9 nssTrustDomain_FindCertificateByIssuerAndSerialNumber () at trustdomain.c:796
10 nssTrustDomain_FindCertificateByEncodedCertificate () at trustdomain.c:839
11 NSSTrustDomain_FindCertificateByEncodedCertificate () at trustdomain.c:852
12 CERT_NewTempCertificate () at stanpcertdb.c:366
13 __CERT_NewTempCertificate () at stanpcertdb.c:474
14 SecurityEnvironment_NssImpl::verifyCertificate() () at xmlsecurity/source/xmlsec/nss/securityenvironment_nssimpl.cxx:524
Change-Id: If334d056a9e13ad806e3ea1a03d395d606fd3d84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133622
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
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>
Unfortunatly we cannot add --disable-scripting to
sub_conf_defaults, because Java currently has no
equivalent to the PYTHON_FOR_BUILD setting.
Change-Id: I89938a17307a363f5de808200914940503312829
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126186
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
As a start, do this only in case there are no effects used. If there is
no theme color or there are effects, fall back to the old code.
Also move parseExportStream() from SdModelTestBaseXML up to MacrosTest,
so oox/ test code can use it as well.
Change-Id: Ia76581dcef110341f6c3e60f22c34818ed0dcabc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126215
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
...as sub-expressions of ternary operators, which happened to keep compiling
after 4b9e440c51 "Turn OStringLiteral into a
consteval'ed, static-refcound rtl_String" and
e6dfaf9f44 "Turn OUStringLiteral into a
consteval'ed, static-refcound rtl_uString" because both branches are of the same
type O[U]StringLiteral<N>, and which didn't cause any issues because no dangling
pointers to those temporary objects escaped the surrounding full expressions.
This was found with an experimental build with VS 2022 with
--enable-latest-c++, which would support HAVE_CPP_CONSTEVAL after some linking
fix in the configure.ac detection code (which is forthcoming in a later commit)
and flagged all these uses in ternary operators as error C7595 "call to
immediate function is not a constant expression". That error looks bogus (and
it also caused a false
> sd/source/ui/unoidl/unoobj.cxx(742): error C7595: 'Color::Color': call to immediate function is not a constant expression
so HAVE_CPP_CONSTEVAL will need to remain undefined for VS 2022 until that
compiler bug is fixed), but it nicely found all these cases that should arguably
be cleaned up.
Change-Id: I81de94e8af5a6c50e5fe7dfa1a4b253e0c2a68f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125082
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tests added in commit 40d70d427e don't
actually run on WNT but that wasn't obvious because commit
149df1fec6 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>
Fedora nss-3.69.0-1.fc34.x86_64 and Debian libnss3:amd64 2:3.70-1 no
longer support the old BerekelyDB databases, so convert them to the new
SQLite format for the benefit of --with-system-nss builds.
This worked to do the upgrade:
> certutil -N -d sql:test/new --empty-password
> LD_LIBRARY_PATH=instdir/program workdir/UnpackedTarball/nss/dist/out/bin/certutil --merge -d sql:test/new --source-dir dbm:test/signing-keys
Builds would fail running tests added in commit
40d70d427e
signing.cxx:551:Assertion
Test name: testODFX509CertificateChain::TestBody
equality assertion failed
- Expected: 0
- Actual : 1
Change-Id: I00aa20703e117ebf583c3331b84e966c2cfc78cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123586
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
...compared to a full-blown O[U]String, for temporary objects holding an
O[U]StringConcat result that can then be used as a std::[u16]string_view.
It's instructive to see how some invocations of operator ==, operator !=, and
O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit
materialization of an O[U]String temporary, and how that expensive operation has
now been made explicit with the explicit O[U]StringConcatenation ctor.
(The additional operator == and operator != overloads are necessary because the
overloads taking two std::[u16]string_view parameters wouldn't even be found
here with ADL. And the OUString-related ones would cause ambiguities in at
least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with
RTL_STRING_UNITTEST, so have simply been disabled for that special test-code
case.)
Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which is a problem in ASan builds, as seen with a failing
CppunitTest_sd_import_tests (among lots of other similarly failing tests):
> Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-11-openjdk-11.0.11.0.9-5.fc34.x86_64/lib/libsystemconf.so: ~/lo/core/instdir/program/libnspr4.so: undefined symbol: __asan_option_detect_stack_use_after_return
> at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
> at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
> at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
> at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
> at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2648)
> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:830)
> at java.base/java.lang.System.loadLibrary(System.java:1873)
> at java.base/java.security.SystemConfigurator$1.run(SystemConfigurator.java:67)
> at java.base/java.security.SystemConfigurator$1.run(SystemConfigurator.java:65)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/java.security.SystemConfigurator.<clinit>(SystemConfigurator.java:65)
> at java.base/java.security.Security.initialize(Security.java:208)
> at java.base/java.security.Security$2.run(Security.java:93)
> at java.base/java.security.Security$2.run(Security.java:91)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/java.security.Security.<clinit>(Security.java:91)
> at java.base/sun.security.jca.ProviderList.<init>(ProviderList.java:176)
> at java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:94)
> at java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:92)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/sun.security.jca.ProviderList.fromSecurityProperties(ProviderList.java:91)
> at java.base/sun.security.jca.Providers.<clinit>(Providers.java:54)
> at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:264)
> at java.base/java.security.SecureRandom.<init>(SecureRandom.java:219)
> at java.base/java.util.UUID$Holder.<clinit>(UUID.java:101)
> at java.base/java.util.UUID.randomUUID(UUID.java:147)
> at org.probatron.officeotron.sessionstorage.Store.putZippedResource(Unknown Source)
> at org.probatron.officeotron.CommandLineSubmission.<init>(Unknown Source)
> at org.probatron.officeotron.Driver.main(Unknown Source)
> warn:svl.items:1258842:1258842:svl/source/items/itempool.cxx:358: old secondary pool: EditEngineItemPool of pool: XOutdevItemPool must be empty.
> ~/lo/core/test/source/bootstrapfixture.cxx:232:SdImportTest::testDocumentLayout
> equality assertion failed
> - Expected: 0
> - Actual : 256
> - failed to execute: sh ~/lo/core/bin/officeotron.sh ~/lo/tmp/SdImportTest__testDocumentLayout_16w8dw.tmp > ~/lo/tmp/SdImportTest__testDocumentLayout_16w8dy.tmp
The solution reuses the arg-env bootstrap variable already used by
test::OfficeConnection::setUp (unotest/source/cpp/officeconnection.cxx) and for
that makes test::getArgumnet available outside Library_unotest. (For
simplicity, it adds the relevant gb_CppunitTest_add_arguments calls
unconditionally to the various *.mk files, even though the data is only used
conditionally for non-_WIN32 in test::BootstrapFixture::validate in
test/source/bootstrapfixture.cxx, at least for now.)
Not sure what exactly started to cause this issue now for my ASan builds on
Fedora 34.
Change-Id: I7a4d6c0e36b94935442c6c91d5ee967fcad61763
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119317
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
After 5c9ba1f47d, the failures on Jenkins
(see 21191d0d89) made it apparent that
(at least some of) Jenkins builds also run in RDP sessions. Since the
tests excluded in commit 9c6142ec26 never
failed in Jenkins builds before, it is wrong to exclude all those tests
in all RDP sessions: our CI would not test those on Windows.
In the meanwhile, I discovered that the system that failed the tests
actually had 16-bit color depth, despite RDP being configured to use
32-bit colors; that was the reason why the colors were modified on
roundtrip. So it is better to test the actual problem to exclude tests.
This reimplements the check that was introduced in commit
9c6142ec26 to test default virtual device
color depth.
Change-Id: I329a3e2d8eca21732c77dcacf15394d1246b2e18
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113460
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
It seems that RDP may change (limit?) color space (even configured
to use 32-bit colors), and then some tests start failing like this:
Test name: BackendTest::testDrawAlphaBitmapMirrored
equality assertion failed
- Expected: c[80000000]
- Actual : c[84000000]
Debugging ImplDrawBitmap in vcl/win/gdi/gdiimpl.cxx, and adding a
call to GetPixel immediately after the call to StretchDIBits, shows
that the resulting color on the device is different from the color
in the bitmap data: e.g., for original color {128, 0, 0} the result
is {132, 0, 0}.
Calling GetColorAdjustment shows that there's no color adjustments
set for the device, so I can't detect or modify the behavior this
way. So just disable the tests for now when running in RDP sessions.
Change-Id: Ie89d07f18f53e56bed6f7fa58432b8575b4d9f12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113388
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
to avoid chasing weird problems where we read past the end
of file, which leads to random data in the variable we read into.
I expect a couple of possible regressions from this change
(1) memory leaks caused by non-exception-safe memory handling.
Of which there should not be much because we're pretty good
about using smart pointer classes these days.
(2) Broken files which used to load, will no longer do so.
These will have to be debugged by putting a breakpoint
on the SvStreamEOFException constructor, and examining
the backtrace to see where we should be catching and ignoring
the exception to make the code continue to handle such broken
files.
Change-Id: I351be031bb083a3484a9a1b650a58892700e6fb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105936
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea "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>
Gabor Kelemen