Extend external/xmlsec/old-nss.patch.1, our bundled NSS in debug builds
has some assert failure in relatively new xmlsec code, just disable it
for now till it's clarified with upstream how to sort that out properly.
E.g. CppunitTest_filter_svg fails like this:
#1 0x00007ffff77503e5 in abort () at /lib64/libc.so.6
#2 0x00007ffff679ca90 in PR_Assert (s=0x7ffff44fbfe5 "oidmechhash != NULL", file=0x7ffff44fbfb6 "secoid.c", ln=2140) at ../../../../pr/src/io/prlog.c:571
#3 0x00007ffff44eaae0 in SECOID_FindOIDByMechanism (mechanism=307) at secoid.c:2140
#4 0x00007ffff6660c65 in PK11_MechanismToAlgtag (type=307) at pk11mech.c:1745
#5 0x00007fffe874e4ea in xmlSecNssCryptoCheckMechanism (type=307) at crypto.c:68
#6 0x00007fffe874ec44 in xmlSecNssUpdateAvailableCryptoTransforms (functions=0x7fffe87ffbc0 <functions>) at crypto.c:401
#7 0x00007fffe874f13d in xmlSecNssInit () at crypto.c:552
#8 0x00007fffe86b2c36 in initXmlSec() () at /home/vmiklos/git/libreoffice/core/xmlsecurity/source/xmlsec/xmlsec_init.cxx:42
#9 0x00007fffdf3c54f2 in DocumentSignatureManager::init() (this=0x7fffffff3970) at /home/vmiklos/git/libreoffice/core/xmlsecurity/source/helper/documentsignaturemanager.cxx:79
#10 0x00007fffdf43e3da in (anonymous namespace)::DocumentDigitalSignatures::ImplVerifySignatures(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, DocumentSignatureMode)
(this=0x1c07ac0, rxStorage=uno::Reference to (OStorage *) 0x1944e18, xSignStream=empty uno::Reference, eMode=DocumentSignatureMode::Macros)
at /home/vmiklos/git/libreoffice/core/xmlsecurity/source/component/documentdigitalsignatures.cxx:486
#11 0x00007fffdf43da17 in (anonymous namespace)::DocumentDigitalSignatures::verifyScriptingContentSignatures(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&) (this=0x1c07ac0, rxStorage=uno::Reference to (OStorage *) 0x1944e18, xSignInStream=empty uno::Reference)
at /home/vmiklos/git/libreoffice/core/xmlsecurity/source/component/documentdigitalsignatures.cxx:373
#12 0x00007fffe6fa06df in SfxObjectShell::GetDocumentSignatureInformation(bool, com::sun::star::uno::Reference<com::sun::star::security::XDocumentDigitalSignatures> const&)
(this=0x188c280, bScriptingContent=true, xSigner=empty uno::Reference) at /home/vmiklos/git/libreoffice/core/sfx2/source/doc/objserv.cxx:1847
Change-Id: I36dee0d2b128a6931875572aa4acc9df940ab623
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161951
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I3d9bd77093d2e6376717d27f105e72ff5a919fe7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144696
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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
1c6382b256 ("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>
...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.
1c9a40299d "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 1c9a40299d):
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>
When initializing for the in-memory database (NSS_NoDB_Init) the
internal slot is read-only so a lot of actions (PK11_ImportCert)
fails. Instead of that we create a new cert/key database inside
the tmp directory and delete it on exit. This way there are no
limitations and all the actions perform as expected.
Change-Id: Iadec5dd8f3459be56ba57d077057eacf3e0797fc
Reviewed-on: https://gerrit.libreoffice.org/65765
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
This was only useful when the mscrypto to mscng porting was in progress.
Change-Id: I5a062cae744489e5ad311ab6b531d00ea21f4e0a
Reviewed-on: https://gerrit.libreoffice.org/57699
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
By making it possible to use libxmlsec's mscng backend instead of the old
mscrypto one which lacks ECDSA support.
make -sr CppunitTest_xmlsecurity_signing SVL_CRYPTO_CNG=1 CPPUNIT_TEST_NAME="SigningTest::testECDSA"
passes with these changes, while it failed in the SVL_CRYPTO_CNG=1 case previously.
Change-Id: Ic23e5af11d271ed84175abe3d5ad008c7cc9e071
Reviewed-on: https://gerrit.libreoffice.org/56370
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
Need to incrementally migrate the remaining places (ODF, OOXML signing)
to CNG, then flip the default. SVL_CRYPTO_CNG=1 is needed till then.
(The testcase passes with and without the fix when SVL_CRYPTO_CNG is not
specified; it fails without the fix when SVL_CRYPTO_CNG is specified.)
Change-Id: Ide9d3b109bbd955a9cb83b18bba6aa72269f4d34
Reviewed-on: https://gerrit.libreoffice.org/55030
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This commit enables HAVE_FEATURE_NSS for Android and fixes the svl/ vcl/
and xmlsecurity/ module to use NSS.
xmlsecurity/ wasn't built for Android previously, this commit enables
building xmlsecurity/ for Android and disables the support of gpgme
in the same module(Only for Android).
It also enables the linking of NSS shared libraries with
liblo-native-code.so and adds a rule to package them along with the apk.
Change-Id: I7d0341688ac979ae92e9145c37dd107670417fe1
Reviewed-on: https://gerrit.libreoffice.org/41308
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This is just a set of C functions accessing public libxmlsec API, it's
perfectly OK to have this in xmlsecurity/ instead of patching the
bundled libxmlsec for this.
Change-Id: Ib3e746883a47b80626fdcd64149ce50aa0588395
Reviewed-on: https://gerrit.libreoffice.org/40209
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
The only remaining difference is that in the system-xmlsec case we work
with the default key manager, not with the one that's only added by our
xmlsec patches.
This works for me for the uses I know of (see
<https://lists.freedesktop.org/archives/libreoffice/2017-February/076947.html>
for the motivation): signing and verifying of different signatures (bad
signature, good with non-trusted CA, good with trusted CA) with
software-based certificates all behave as expected.
Change-Id: If3f3e2b8373ab7397db3f98070a5a2ce51fa7c06
Reviewed-on: https://gerrit.libreoffice.org/39075
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
In the end, the gpgme implementation uses enough of xmlsec
functionality that splitting those (and ending up with two copies)
was just not worth it.
Change-Id: Ida87c848e4e6a770e3c697add9ceb589a9ec3930
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Note: do NOT put file paths to static libraries into FOO_LIBS variables
that are passed to bundled externals that are built with --enable-static:
on Mac OS X this will result in .a archives that contain other .a
archives as entries, and trying to link those results in errors like:
ld: warning: ignoring file .../libodfgen-0.0.a, file was built for
archive which is not the architecture being linked (i386)
Change-Id: If2c5a458058e4da76f80b3643e55b489d1edee24
- do not use gb_UnpackedTarball_copy_header_files for boost
- adapt the optimization in concat-deps.c for new path
- use boost_headers in all LinkTargets that require it
- add explicit include paths to mysqlc, mysqlcppconn, libvisio, liborcus
Change-Id: I0c43e73ed43cc9d2e6bce8faf55e992d655a0bb9
GUI only takes values UNX or WNT, so it is fairly pointless. One can check
whether OS is WNT or not instead.
Change-Id: I78ae32c03536a496a563e5deeb0fca78aebf9c34
Reviewed-on: https://gerrit.libreoffice.org/1304
Reviewed-by: Peter Foley <pefoley2@verizon.net>
Tested-by: Peter Foley <pefoley2@verizon.net>
...past 8648c974ea "Clean-up 'SYSTEM_MOZILLA' ->
'SYSTEM_NSS.'" Looks like -DSYSTEM_MOZILLA in RepositoryExternal.mk's
gb_LinkTarget__use_nss3 was only relevant for
xmlsecurity/source/xmlsec/nss/nssinitializer.cxx (for which it had been set
explicitly in xmlsecurity/Library_xsec_xmlsec.mk, and renamed to SYSTEM_NSS
already). And looks like xmlsecurity/Library_xsec_xmlsec.mk's explicit
SYSTEM_NSS code was more or less a duplication of RepositoryExternal.mk's
gb_LinkTarget__use_nss3, so made that DRY.
Change-Id: Ie6eca2c4eb7fb70f6a36c97d8681b4140f9870cb
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
add a new gb_LinkTarget_use_system_win32_libs to abstract different
linker options on MSVC and GCC.
Change-Id: Ic9bf2545f59bf7871e6fc06b290c486ddfbec03d
Christian Lohmaier