xsec_xmlsec.dll is linked to libxmlsec-mscng.dll, which is
linked to Win32 bcrypt.dll, which doesn't have BCryptKeyDerivation on
Windows 7.
Use GetProcAddress() to retrieve BCryptKeyDerivation at runtime; the
function is not used by LibreOffice.
(regression from commit 26bf26272b
and (due to revert) commit bfd479abf0)
Change-Id: I0c0c94ee0cdfd48ae7506d9dfb51fcaf8289d460
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163709
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The problem in the new code was that previously xmlSecNssInit() didn't
require an already initialized NSS, but 1.3.3 did.
Backport upstream fix that restores the old behavior that NSS init is
not needed, which allows no longer reverting the
xmlSecNssUpdateAvailableCryptoTransforms() call that upstream added
recently.
Change-Id: Ie33ccbff0149e3c406d5574e889d90da4fdbbfb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162292
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
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>
This time try to do it in a way that doesn't re-introduce tdf#155034,
i.e. patch out code that would use NSS symbols which are in the RHEL7
baseline, but are not in Ubuntu 18.04. This is all code like RSA OAEP or
AES GCM which is relatively new, so not really required for our
signature needs.
It also helps that this release has a lowered baseline for NSS.
Change-Id: I5a8df6d98462e8173a5508e014bd2d515da2dc9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152747
Tested-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
- remove the fix-size_max-412.patch.1 and
remove-unnecessary-macro-417.patch.1 backports
- drop old-nss.patch.1, which is now upstream
Change-Id: I4b668d4949d8831cffbe87ac6b16a20ba8698128
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142395
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This is basically ea68de2968 but
for LDFLAGS. A number of external libs cannot use this because
their libtool mishandles -fuse-ld.
Change-Id: Idee379eb0a3afb475b536519ee3de064b4e218f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133639
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
No idea why we just provided the platform flags when cross-
compiling. In the curious case, where the host platform is
detected as x86_64-pc-mingw32 per default and we actually
want to override it with x86_64-pc-cygwin, we don't do a
cross compile, but must override the host platform.
But there is additional special handling needed for the omitted
cross-platform build in the special case of --host=i686-pc-cygwin
and --build=x86_64-pc-cygwin, where we deliberatly ignore cross
building; Windows is already a slow build, so try to keep this
optimization (AMD64 can execute x86 binaries).
There is the theoretical case, where the externals config.guess
would have detected something else and that "magically" even
worked, while the LO detected triplet would fail, but this
should be fixed in the external in any way.
Change-Id: Ib7a9719e0e406fe90334b7611dc3f01b51692bfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129153
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
- align with most of the rest of config_host
- rename DISABLE_OPENSSL to ENABLE_OPENSSL
- make this configurable
Change-Id: Ic3b41fcdda38db66134939f12265e0da24833d60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114564
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Duplicate ds:X509Certificate elements cause:
warn:xmlsecurity.comp:9604:3820:xmlsecurity/source/helper/xmlsignaturehelper.cxx:658: X509Data do not form a chain: certificate in cycle:
(regression from 5af5ea893b)
Change-Id: I3d319a2f74dbec17b73f1c7bb8f4efe4e335f0ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113746
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
See instructions in solenv/gbuild/Trace.mk . This generates a file than
can be viewed e.g. in the Chromium tracing view.
Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
...which was at maximum set to GCC's -finline-limit=0 -fno-inline
(solenv/gbuild/platform/com_GCC_defs.mk). Those options were set for debug
builds "since forever", but that looks very much like cargo cult: -fno-inline
"is the default when not optimizing" anyway
(<https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html>), and it
is unclear to me how -finline-limit=0 should have any impact beyond -fno-inline
(and maybe was present for ancient compilers that only supported -finline-limit
but not -fno-inline?).
Change-Id: Id6752d03b1b7ec8763defabc5720d4dd08790874
Reviewed-on: https://gerrit.libreoffice.org/66836
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This was patching the nmake build system for nss purposes, but we use
nss on Linux/macOS only, and there we use the autotools build system, so
this patch had no effect at the end.
Change-Id: I0f0c3e0d045818ad3e456dd49017ae328ef6e053
Reviewed-on: https://gerrit.libreoffice.org/63385
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This gets rid of the horrible hack in gbuild.mk to accomodate the
case-incorrect iOS platform makefiles that cannot be renamed without
upsetting git on file systems that sadly lack the case sensitivity
feature.
Keep the macro defined to IOS though.
Change-Id: I1022bfef4900da00e75fc1ccce786b20f8673234
Reviewed-on: https://gerrit.libreoffice.org/62705
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Commit 2d1e4290a9 (Merge Gentoo patches
from old build and downstream repositories., 2011-03-13) mentions this
was necessary for libxml-2.7.8, but xmlsec already depends on 2.8.0 and
the same "extern block starts before the include list" pattern is there
in every other xmlsec header, so the patch was incomplete anyway.
Change-Id: I33fadcb3e5583266a37cf7f240b27b2df1544040
Reviewed-on: https://gerrit.libreoffice.org/60782
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Allows dropping the xmlsec1-ecdsa-assert.patch.1 backport.
Also fix the generated test certs + generator script to avoid expired
certs for a while (.db files generated with Firefox 57.0).
Change-Id: I8cba9a01633a3952c845e15e23b18d44544cdb59
Reviewed-on: https://gerrit.libreoffice.org/56123
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This was added in commit ebd1b95bb5
(INTEGRATION: CWS xmlsec08 (1.1.2); FILE ADDED; 2005-03-10) without any
real commit message to explain why this is necessary.
system-xmlsec (not containing this patch) works fine for our XML signing
purposes with software certificates, and just recently I learned that
even hardware-based certificates work fine without this patch, so it can
go away.
I assume this was a refactor to allow some new feature as a next step,
but that feature was never implemented.
Change-Id: I31639230483cd34b14b35fd41b4fcd8284476138
Reviewed-on: https://gerrit.libreoffice.org/55296
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Caolán McNamara