| Age | Commit message (Collapse) | Author |
|---|
|
This allows to build a complete static LibreOffice on Linux,
except for linked externals. Since LO's static build implies
disabled dynamic loading, one must select one VCL backend to
be compiled in.
See the (large) comment in solenv/gbuild/static.mk trying to
explain, why this implementation was chosen (spoiler: seems
there is no other way) and what is actually implemented.
This will collect all libraries, statics and externals of
executables. If the executable uses components, it will get
linked to all static components. While it works with any
Executable, it just makes sense for soffice.bin, because the
static component map sucks every dependency in, bloating most
other binaries.
In theory on could generate the dependencies based on the list
of used components (see gb_CppunitTest_use_components), then
generate a specific static constructor map, directly include it
in the exe's cxx code and then link the minimal dependencies.
The static LO should build on Linux with:
--enable-customtarget-components
--disable-dynamic-loading
Tested VCL plugin config is:
--disable-gtk3
--disable-gen
--enable-qt5
The partial build support is split into a 2nd patch.
Change-Id: Iafc95752fae9e88095f54a21f1e30a4f080815e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126790
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
x509.h includes cert.h. But that doesn't know of LO using
xmlsecurity/source/xmlsec/nss/nssrenam.h, which has a "#define
CERT_DecodeDERCertificate __CERT_DecodeDERCertificate". So the PCH
doesn't know of this rename and the compiler fails.
move the include line into the file that needs it and the --enable-pch=full
build works ok
Change-Id: I247bd219cf47964490ded439ad51bd8e8e120c48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127744
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Jenkins
|
|
We have two environments where the signature and the stream bytes are
the same, still in one case the signature verification succeeds and in
the other case the hash doesn't match.
Log the signature as parsed into a DOM node (recursively), just case
something goes wrong during extracting a single signature from the
signatures list XML.
Change-Id: I54af71fdeb63d8ef44342f106746f938fa51f29a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127991
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
* remove GPGME_CAN_EXPORT_MINIMAL_KEY, upstream now has support for
key export flags in c++ wrapper (gpgmepp >= 1.14)
* therefore, external/gpgmepp/add-minimal-keyexport.patch now fully
obsolete, tweaked xmlsecurity code to use upstream function
* bits of external/gpgmepp/find-libgpg-error-libassuan.patch are
upstream now (configure and makefile pieces, though we keep
configure.ac changes for the while - to not pick up system versions
too easily)
* external/gpgmepp/gpgme.git-fe2892618c20cd40c342cce26ffb6ac4644fd3c3.patch.1
was from upstream anyway, removed
Change-Id: I991c20c0eeff0f9135e97c991afcb905be55a959
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127665
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
We can already see if a signature verification fails and what is the
content of the ZIP streams we hash.
Show what is the expected hash as well.
Change-Id: Ibc67b7de0e8d03e06da1b86b6e8a7b2b2e613882
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127934
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
One non-obvious hunk is the dependency of GPG based on NSS. While
it doesn't need NSS per-se, the signature validation code uses
NSS functions.
This is mainly an improvement / has the same origin then commit
1c6382b2564fbf19f8ee99e11021dff2ce19ed6f ("xmlsec: handle missing
EqualDistinguishedNames").
Change-Id: I12416139e1e391822d878c61b4ed06f3a409c334
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127913
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
We only get:
warn:xmlsecurity.xmlsec:32272:32272:xmlsecurity/source/xmlsec/errorcallback.cxx:53: digests.c:226: xmlSecNssDigestVerify() 'sha1' '' 12 'data and digest do not match'
when one of the XML streams have a bad hash. Add some logging to help
figuring out (without a debugger) which stream is at fault.
Change-Id: Ib5f39df87bcdaaac1a21eb560c8f775c42a4079f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127885
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I5b04f7adf11c61f52b7bfb0f52c8c075f838f0f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127480
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I0a457dc8ddccc0fce42032956aff6d661d1ae80a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127403
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I52e6588f5fac04bb26d77c1f3af470db73e41f72
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127193
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
...instead of by listing the content somewhat redundantly in the Rdb_*.mk
files, to avoid duplication of logic for components that are only built
conditionally (and thus should only be included conditionally in the
corresponding Rdb). To achieve that, add an "rdb" parameter to
gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros
that internally call gb_ComponentTarget_ComponentTarget), which is used to make
the appropriate gb_Rdb_add_component call internally from within
gb_ComponentTarget_ComponentTarget. (As a special case,
gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that
has already been done by the corresponding gb_Library_set_componentfile call, so
allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to
support that special case.)
Most Rdb_*.mk files are thus mostly empty now. One exception is
i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as
needed during the build in CustomTarget_i18npool/localedata.
1c9a40299d328c78c035ca63ccdf22c5c669a03b "gbuild: create services.rdb from built
components" had already tried to do something similar (in addition to other
things) under a new --enable-services-rdb-from-build option. However, that
approach had four drawbacks that this approach here addresses (and which thus
partly reverts 1c9a40299d328c78c035ca63ccdf22c5c669a03b):
1 Rdb_services shall not contain the component files of all libraries that are
built. While that commit filtered out the component files that go into
Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files
that go into others like Rdb_postgresql-sdbc
(connectivity/Rdb_postgresql-sdbc.mk).
2 The code added by that commit to Makefile.gbuild codified the knowledge that
there is an Rdb_services, which is brittle.
3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge
(for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle.
4 Introducing an --enable-services-rdb-from-build option needlessly provided
two different ways how the content of Rdb_services is assembled.
The changes done here would leave --enable-services-rdb-from-build as a
misnomer, as it no longer controls how Rdb_services is assembled. I thus
renamed it to --enable-customtarget-components, as that is apparently what it
still does now.
Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib482e3982128dc47d88a79478d80eef43745d1b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126086
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1597a8e77199445bf377dbe54adc3134bb04fd51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125748
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I54c33508639044092356eed5144720261b4f65db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124816
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
...that had inadvertently been missing from
a5cea74034a8e029bfdf0f2b82ea8800bf5bd206 °Fix misuses of NULL across
Windows-only code"
Change-Id: I8f60cd6114ceb7c6413fb099778bfb06407bbb24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124431
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7cfcf9f9ea307bd737292e6f4f37a29f453167c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124418
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
(not a typo according to the comment at
<https://gerrit.libreoffice.org/c/core/+/124287/3#message-df56362ec7d674eaab3fe81bb0827be81ee5686d>
"xmlsecurity: some Distinguished Names are less equal than others": "i was too
lazy to look up which integer would be returned by the function and hoped this
would convert it to bool anyway"
Change-Id: I0f4f4d19e8d382f4430023aa6f9459c66a605b04
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124321
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
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>
|
|
Change-Id: I6adc2cb0a07eb08a50c610958983493f4f8031ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124021
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
|
|
Change-Id: I3b4226a9d089ec9aedab95d96e50a068f57a76c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123991
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ifd1068066c8711a1fa96ff4ede1fa0017a221617
|
|
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>
|
|
Change-Id: Ib9bd9b96d28c9c4dd0fa36a82a177e119aa04e6b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123820
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The problem with commit ff572d9222ec16ffd679ae907a0bf4a8900265e1
is that it's using the wrong library; NSS_SetAlgorithmPolicy is actually
in libnssutil3.so.
This causes a linking problem when upgrading the internal NSS to a
version that has NSS_USE_ALG_IN_ANY_SIGNATURE.
Change-Id: I954d88062c38881bc721bdf052db4f7b55888aae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123819
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
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>
|
|
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>
|
|
These 2 calls to CertAddStoreToCollection follow calls where
m_hCertStore was already added and according to the comments they
should add the other store instead.
(regression from commit 813e1f5a8ae4800e8a11c612de4e3b0a97f1368d)
Change-Id: If375f603647a702feb0ca8f272126a15d5d0e906
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123666
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I749e19f786ad006dffcd65dd1ee60e57c428f57b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123717
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ia19ffa1213d578c30f35545bcca515669e7ff7a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123710
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
... 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>
|
|
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>
|
|
Change-Id: If50ae8156f81c1053aa8fbfc3148da64bb8e1442
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111666
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
|
|
Change-Id: I6ce64ca7c59639684779144ed0ed8d36c4aca32b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111665
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I3ce77ab82529f13c5e55ea30c813f66cb5180877
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123369
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idd014c93e2e85d2ffc7a2535a9c65cffc8a9d403
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123348
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6dea009e1031174ecb3d4371e91c9c6d26c6e514
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123245
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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>
|
|
Change-Id: I8a08b0382121355c70284c2e85375ba6c3671553
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122468
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I9b35d6333afa6b305bf73fc55a7e60c8365674e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122134
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
- Revise uses of getSomething to use getFromUnoTunnel
Where that is impossible, use getSomething_cast to unify casting,
and minimize number of places doing low-level transformations.
The change keeps the existing tunnel references that last for the
duration of the pointers' life, because sometimes destroying such
reference may destroy the pointed object, and result in use after
free.
Change-Id: I291c33223582c34cd2c763aa8aacf0ae899ca4c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122101
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
- Change implementations of getSomething to use getSomethingImpl
Or where that's impossible, use getSomething_cast to unify this and
reduce number of places where we reinterpret_cast.
All static methods getting tunnel ids were renamed to getUnoTunnelId,
to comply with the convention used in <comphelper/servicehelper.hxx>.
TODO (in separate commits):
- Revise uses of getSomething to use getFromUnoTunnel
Change-Id: Ifde9e214b52e5df678de71fcc32d2199c82e85cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122100
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
- Replace all uses of OImplementationId in core with UnoIdInit
- Deprecate OImplementationId in <cppuhelper/typeprovider.hxx>
OImplementationId uses broken double checked locking; additionally,
it uses it at the first call to getImplementationId, not when the
object is constructed. This implementation can't be changed, cince
it's part of published API; it can't rely on C++11, which would be
required for use of thread-safe statics and move the initialization
to ctor.
The class has obsolete _bUseEthernetAddress member, that is unused
and ignored since 4e9fa7e339a1cd6cb2fec643715991bcf5057cec. No need
to implement it when replacing its uses to UnoIdInit.
The deprecation is the API CHANGE. No published API is introduced to
replace it; 3rd-party code should seek alternative solutions, or just
keep using the deprecated functionality.
TODO (in separate commits):
- Change implementations of getSomething to use getSomethingImpl
- Revise uses of getSomething to use getFromUnoTunnel
Change-Id: I8b6e684e5389bc0d5bb3b7f21f72a4c8f684107d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122077
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The header got some changes:
1. Move UnoTunnelIdInit and isUnoTunnelId into 'comphelper' namespace
2. Rename UnoTunnelIdInit to UnoIdInit, as a precondition to replace
of uses of OImplementationId with it, including in XTypeProvider
3. Introduce convenience functions 'getSomething_cast' to cast between
sal_Int64 and object pointers uniformly.
4. Rename getUnoTunnelImplementation to getFromUnoTunnel, both to make
it a bit shorter, and to reflect its function better. Templatize it
to take also css::uno::Any for convenience.
5. Introduce getSomethingImpl, inspired by sw::UnoTunnelImpl; allow it
handle cases both with and without fallback to parent.
6. Adjust UNO3_GETIMPLEMENTATION_* macros
TODO (in separate commits):
- Drop sw::UnoTunnelImpl and sw::UnoTunnelGetImplementation
- Replace all uses of OImplementationId in core with UnoIdInit
- Deprecate OImplementationId in <cppuhelper/typeprovider.hxx>
- Change implementations of getSomething to use getSomethingImpl
- Revise uses of getSomething to use getFromUnoTunnel
Change-Id: If4a3cb024130f1f552f988f0479589da1cd066e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122022
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Iede70151af052505b780c6ce708aa74d97da5c75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121545
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Note that because of where the fix resides, loplugin:redundantcast
also notices a few more things.
Change-Id: I0b66047fadfff2c5ceafcbd3eab085de00d861a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120865
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia89059eea51ca396a7c74143625ac9a6706de198
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120773
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: Ic7410f836e584df45101e78e345c8b3c8d355e09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120680
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(for std::unique_ptr, with recent libstdc++ 12 trunk)
Change-Id: I61b7823dd740ea7cdfe0d7403a50ac73b24d1c4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120229
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
