summaryrefslogtreecommitdiff
path: root/external/libxmlsec
AgeCommit message (Collapse)Author
2017-09-15consistent naming of externals: libxmlsec -> xmlsecMichael Stahl
Change-Id: I9774dbec91b397d291d8f7f9bf96bbb75fc2baad Reviewed-on: https://gerrit.libreoffice.org/42298 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-09-15consistent naming of externals: xml2 -> libxml2Michael Stahl
Change-Id: Ia1164c70d02dce70cb346c1fd4033f12d91c6e5d Reviewed-on: https://gerrit.libreoffice.org/42297 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2017-08-23Fix and enable libxmlsec build for AndroidGautam Prajapati
This commit removes the OpenSSL dependency unconditionally from external/libxmlsec/ExternalProject_xmlsec.mk. xmlsec wasn't built for Android previously but it seems like Android was the only user of xmlsec OpenSSL backend. Now we have NSS built for Android as well, so it's safe to remove the OpenSSL dependency. Change-Id: I8652487be146c3ac643c4f6dc7a6a2845093c93f Reviewed-on: https://gerrit.libreoffice.org/41288 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-07-20xmlsecurity mscrypt: turn akmngr patch into plain codeMiklos Vajna
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>
2017-07-06libxmlsec: no need to build the gcrypt backend on Linux/macOSMiklos Vajna
We only use the NSS one. Change-Id: I84c89cb22a1b880d59ada4b68167e14c1223a177 Reviewed-on: https://gerrit.libreoffice.org/39618 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-06-22--enable-optimized should be orthogonal to --enable-debug/--enable-dbgutilStephan Bergmann
Change-Id: I277f30129560ea9fa76d6439a60bb191358df99d Reviewed-on: https://gerrit.libreoffice.org/39088 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2017-06-14xmlsec: drop vc9 hunk from xmlsec1-vc.patch.1Miklos Vajna
This was added in commit 36ad473eeeace151af341869b0436fac8b1bdd2e (Build fixes for VC++ 10, 2010-10-20) where it was only safe to conditionally add support for Visual Studio 2010. Change-Id: I62c4aefd39a5943259a5a1e462f4762c1aac5e1e Reviewed-on: https://gerrit.libreoffice.org/38768 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-06-09external: drop mingw bits from ExternalPackage_xmlsecMiklos Vajna
Change-Id: Icd0526c0bf0183b80bc4c098e3307574b8b8bb8b Reviewed-on: https://gerrit.libreoffice.org/38592 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-05-31libxmlsec: drop no longer needed xmlsec1-nssdisablecallbacks.patch.1Miklos Vajna
Before the gbuild conversion in commit ec6af4194e80f5f0b2e46ca59802ff397a2a4a24 (convert libxmlsec to gbuild, 2012-11-29) the makefile.mk had a comment for this patch: "Disable use of smime3 so don't need to package it". Today smime3 is packaged (see external/nss/ExternalPackage_nss.mk), so patching xmlsec is no longer needed. Change-Id: I73ec13ee92a1860f5dc3cbeed0e51d42a0320baa Reviewed-on: https://gerrit.libreoffice.org/38239 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-05-25xmlsec: use configure flags instead of patching out apps/docsMiklos Vajna
These flags are new in xmlsec-1.2.24. Change-Id: If32faa6e1d3a5f51fa4d631973d8bd0962783a34 Reviewed-on: https://gerrit.libreoffice.org/38004 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-05-18external/libxmlsec: Pass down gb_VISIBILITY_FLAGSStephan Bergmann
...otherwise ASan build started to fail in CppunitTest_services with > ==16664==ERROR: AddressSanitizer: odr-violation (0x7f4583587440): > [1] size=35 'xmlSecNs' strings.c:22:15 > [2] size=35 'xmlSecNs' strings.c:22:15 > These globals were registered at these points: > [1]: > #0 0x44f410 in __asan_register_globals.part.11 /data/sbergman/github.com/llvm-project/llvm-project-20170507/compiler-rt/lib/asan/asan_globals.cc:358 > #1 0x7f458295cded in asan.module_ctor (instdir/program/libxsec_gpg.so+0x197ded) > > [2]: > #0 0x44f410 in __asan_register_globals.part.11 /data/sbergman/github.com/llvm-project/llvm-project-20170507/compiler-rt/lib/asan/asan_globals.cc:358 > #1 0x7f45833cc28d in asan.module_ctor (instdir/program/libxsec_xmlsec.so+0x5da28d) > > ==16664==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0 > SUMMARY: AddressSanitizer: odr-violation: global 'xmlSecNs' at strings.c:22:15 > ==16664==ABORTING after cae5f2a543b31552ccd9765aca5eb514fa694e07 "gpg4libre: initial GPG signature generation" Change-Id: I689241df52a7e878bfbd2d3dd6409bf0c104638b
2017-05-17xmlsecurity: use xmlsec API instead of patching out cert verificationMiklos Vajna
This flag does exactly what we need since xmlsec-1.2.24. Change-Id: I3ae052d4bfe564c3234aef2511ef82ebdb452ebe Reviewed-on: https://gerrit.libreoffice.org/37700 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-05-10Upgrade libxmlsec to 1.2.24Miklos Vajna
Upstream changes interesting for us: - Added ECDSA-SHA1, ECDSA-SHA256, ECDSA-SHA512 support for xmlsec-nss, so we can drop 2 patches - Fixed XMLSEC_KEYINFO_FLAGS_X509DATA_DONT_VERIFY_CERTS handling, which allows dropping xmlsec1-noverify.patch.1 in the future Also backport a patch from xmlsec master that fixes signature creation on Windows (the release regressed in this regard). Change-Id: I2c14328283bf7d4f8af5595ea4c1efc29ee81f9e
2017-05-05libxmlsec: remove xmlsec1-nssmangleciphers.patch.1Miklos Vajna
This was added in commit ebd1b95bb5f9235d1dba1b840fd746c9b53320d2 (INTEGRATION: CWS xmlsec08 (1.1.2); FILE ADDED, 2005-03-10). According to CWS history it was introduced in the 1.1.2.1 part, without any further comments. Before the gbuild conversion in commit ec6af4194e80f5f0b2e46ca59802ff397a2a4a24 (convert libxmlsec to gbuild, 2012-11-29) the makefile.mk had a comment for this patch: "Dubious, do we still need this ?". My best guess is that this was added as part of some effort to do ODF encryption (not just signing) in xmlsecurity, but code for that on the xmlsecurity part is already removed. Change-Id: I3a5f1fedd7ce10b8b874bb8a3c9e6260213fbd8f Reviewed-on: https://gerrit.libreoffice.org/37261 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2017-03-08tdf#105983 libxmlsec: backport NSS / ECDSA patchesMiklos Vajna
NSS already supported ECDSA, and LibreOffice itself is agnostic here. All what was missing is the ECDSA wrapper in xmlsec's nss backend. Change-Id: Ic26cef369d0f4a1847b6a76825b9464837fe8f3b Reviewed-on: https://gerrit.libreoffice.org/34966 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-02-10Remove MinGW supportStephan Bergmann
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>
2016-12-21Don't add empty TODO functions to libxmlsec, and don't call themTor Lillqvist
Change-Id: Iaec1de29a0e7f3ea8eb10869382401d121de2c8a
2016-11-17libxmlsec: remove no longer applying mingw patchesMiklos Vajna
One from the two patches do not apply anymore. Remove both of them for now. Change-Id: I8e06cc28810a9dac13054282a630b0e9b716af86 Reviewed-on: https://gerrit.libreoffice.org/30924 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-11-04Upgrade libxmlsec to 1.2.23Miklos Vajna
Obsoletes xmlsec1-win32-fix-undeclared.patch.1. Change-Id: I11cd52aebbe5ab224de9ab00b74c02abb46296f6 Reviewed-on: https://gerrit.libreoffice.org/30539 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-10-23don't build libxmlsec docsDavid Tardon
Change-Id: I2fd3283147296e3c392a9d282b762b77e473b3eb
2016-08-02libxmlsec: drop xmlsec1-keyinfo-revert.patch.1 completelyMiklos Vajna
And instead attempt to set up the test environment correctly. Change-Id: I06c10b96749c0464da8d2dd9a59b48f16baeead5 Reviewed-on: https://gerrit.libreoffice.org/27785 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-07-29xmlsec: xmlsec1-keyinfo-revert.patch.1 is not needed on WNTMiklos Vajna
Change-Id: I1dbb6bf57dc78f321e6e6d69b7e573309aff8f48 Reviewed-on: https://gerrit.libreoffice.org/27658 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-07-27libxmlsec: mark part of xmlsec1-vc.patch.1 as upstreamedMiklos Vajna
Change-Id: I4a8365c98eef87274ae1809047fd4ea582102f0b Reviewed-on: https://gerrit.libreoffice.org/27556 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-07-20libxmlsec: switch to using upstream 'compile' scriptMiklos Vajna
Upstream used to provide no such one, and it's needed for the macOS build. Latest upstream release does provide one, no need to patch it. Change-Id: I2c2350d0e074f58d13fedb0d72888dd24ac41f44 Reviewed-on: https://gerrit.libreoffice.org/27322 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-07-14Upgrade libxmlsec to 1.2.22Miklos Vajna
No major changes for us, except that finally we bundle the latest upstream (but still heavily patch it). Change-Id: I6bcfcdf48ec5d25eb3f7b14c89838942b4a11b48 Reviewed-on: https://gerrit.libreoffice.org/27196 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-07-11Break gb_DEBUGINFO_FLAGS out of gb_DEBUG_CFLAGSStephan Bergmann
...in preparation of making them orthogonal Change-Id: If75b334c954138b3aed4f8d1ac33061a2267ad52 Reviewed-on: https://gerrit.libreoffice.org/27056 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-07-08Upgrade libxmlsec to 1.2.21Miklos Vajna
Obsoletes xmlsec1-ooxml.patch.1 and xmlsec1-vs2015.patch.1. Adds xmlsec1-keyinfo-revert.patch.1 till the LO side is adapted to the new xmlsec requirements. Change-Id: I1a46ad8fd7e9c8b4fa7a97591a1d90922969393d Reviewed-on: https://gerrit.libreoffice.org/24403 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-05-24respect verbose in external/libxmlsec/ExternalProject_xmlsec.mkRene Engelhard
as for the other external libs Change-Id: I3d397b3d0afde3df9032cf52dd82d59427924c20
2016-04-22pass original CFLAGSDavid Tardon
Change-Id: Ia37fa1ad21a9411d78b0c30c769b3934d43d1389
2016-04-20libxmlsec: split the upstreamed part of xmlsec1-vc.patch.1 into a new patchMiklos Vajna
Change-Id: I1a6201a21cdf3a42475487a42cd80d11cd5e42b6 Reviewed-on: https://gerrit.libreoffice.org/24253 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-04-13Upgrade libxmlsec to 1.2.20Miklos Vajna
Obsoletes xmlsec1-update-config.guess.patch.1. Also update xmlsec1-ooxml.patch.1 as it was upstreamed at the end (with improved error checks, etc), which wasn't possible before without loads of conflicts. Change-Id: I6fee428f73f8908289d87cc262ad323ec62e65cf Reviewed-on: https://gerrit.libreoffice.org/24032 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-04-06Upgrade libxmlsec to 1.2.19Miklos Vajna
Obsoletes our xmlsec1-1.2.14-ansi.patch.1 and xmlsec1-android.patch.1. Change-Id: Ic6499b1a79e3f5a6d94beb62c0c338789c782c86 Reviewed-on: https://gerrit.libreoffice.org/23844 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-03-25Upgrade libxmlsec to 1.2.17Miklos Vajna
So we can drop xmlsec1-configure-libxml-libxslt.patch.1, as upstream commit be72c468dfd3165105ed5cdc949493332c4d3064 (fixed configure issue with emapty --with-libxml/libxsl and config scripts in /bin directory, 2010-07-19) fixes the same problem. Change-Id: Ibb01fb2c5e4074d39168df487180fa88c7bb8035 Reviewed-on: https://gerrit.libreoffice.org/23498 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-03-23xmlsec: clean up the nss keywrapper part of xmlsec1-customkeymanage.patch.1Miklos Vajna
All of this is already provided by src/nss/kw_*.c. If I build xmlsec as a shared lib, I even get linker errors due to duplicated symbols. For some reason that does not show up in our situation where we build nss as a static lib and link to it in xmlsecurity. Change-Id: If6e00bf3a818a0146c9c30c51174d8e0acab43a9 Reviewed-on: https://gerrit.libreoffice.org/23443 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-03-18Upgrade libxmlsec to 1.2.16Miklos Vajna
No instant drop of any of our patches this time, but a considerable amount of xmlsec1-customkeymanage.patch.1 is now redundant, as part of the key wrapper code is available in this upstream release for both mscrypto and nss. But that can be cleaned up in a separate follow-up commit. Change-Id: I197eaffe3a52f2f9c02af982872185e017965006 Reviewed-on: https://gerrit.libreoffice.org/23344 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2016-03-10Upgrade libxmlsec to 1.2.15Miklos Vajna
The primary benefit is that this release supports sha256 out of the box, so we can drop xmlsec1-nss-sha256.patch.1 and xmlsec1-mscrypto-sha256.patch.1. Change-Id: I78606c02591ac8ae7e347b0faa510ae2483e3183 Reviewed-on: https://gerrit.libreoffice.org/23096 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2016-03-07libxmlsec: move new files back to xmlsec1-customkeymanage.patchMiklos Vajna
That was the situation before commit ec6af4194e80f5f0b2e46ca59802ff397a2a4a24 (convert libxmlsec to gbuild, 2012-11-29), and if we ever manage to upstream this patch, then it'll just make the review process harder if half of the patch is in separate files. Change-Id: I0d12d72ea7a1a2591d1ef5232c006b6b7fea7aff Reviewed-on: https://gerrit.libreoffice.org/22973 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-03-02libxmlsec: start tracking patch upstreaming effortMiklos Vajna
Change-Id: I45519896d745bcc4162d655746585051d47b732d
2016-02-25libxmlsec: remove no longer needed xmlsec1-olderlibxml2.patchMiklos Vajna
I assume this was needed for the Linux baseline. CentOS 6 has libxml 2.7.6, patch is needed for < 2.7.4. (CentOS 5 had 2.6.26, that is only used on libreoffice-5-0). Change-Id: Iae2edbf4f0d484944e399bd901d35a8260272700 Reviewed-on: https://gerrit.libreoffice.org/22659 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Jenkins <ci@libreoffice.org>
2016-02-15libxmlsec: fix failing CryptCreateHash() with CALG_SHA_256Miklos Vajna
Previously it got a PROV_RSA_FULL provider, but SHA-256 needs PROV_RSA_AES. Change-Id: I6c689a4c5943920ce656c09d9d7d5e194ff47eb6 Reviewed-on: https://gerrit.libreoffice.org/22364 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-02-03tdf#76142 libxmlsec: implement SHA-256 support in the mscrypto backendMiklos Vajna
The only tricky part is PROV_RSA_FULL -> PROV_RSA_AES, otherwise SHA-256 is not recognized as a valid algo. MSDN documentation for PROV_RSA_FULL at <https://msdn.microsoft.com/en-us/library/windows/desktop/aa387448%28v=vs.85%29.aspx> and PROV_RSA_AES at <https://msdn.microsoft.com/en-us/library/windows/desktop/aa387447%28v=vs.85%29.aspx> say that AES is a superset of full, so should be no backwards-compatibility issue. I tested this on Windows 7, but according to the documentation, it should be no problem on Windows XP, either -- provided that the latest SP is installed. Change-Id: I3ae196679c2cbf0e9e55fab10584d9c46a480659
2016-01-27tdf#76142 libxmlsec: fix xmlSecNssDigestVerify() for SHA-256Miklos Vajna
With this, SfxObjectShell_Impl::showBrokenSignatureWarning() is no longer triggered for the SHA-256 bugdoc. Change-Id: I7a2c5c8517c757e2983f57a3a5908abb941e7a04
2016-01-27libxmlsec: sort elements in OOXML RelationshipTransformMiklos Vajna
The spec says that the implementer shall sort relationship elements by Id value in lexicographical order, so do that before the filtering of these elements. With this, all streams validate for a test document that is supposed to be valid, though xmlSecDSigCtxVerify() still reports errors. Change-Id: I9d9cd511eaebad1f13f4e06891b2a3f61fee4500
2016-01-27libxmlsec: initial OOXML RelationshipTransformMiklos Vajna
Replace the canonicalization with the steps of actions required by ECMA 376, part 2, pages 49 - 70: - parse arguments of the transformation, a SourceId whitelist - add missing TargetMode attributes The largest part is to actually keep the data unchanged, everything still needs to be printed, as the source is a parsed XML tree, while the output is a byte buffer. With this, the first _rels/.rels stream of the OOXML document validates for a test document that is supposed to be valid. Change-Id: Ie996d93de6a7611bac18a8c37c575363552fdab4 Reviewed-on: https://gerrit.libreoffice.org/21832 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2016-01-26tdf#76142 libxmlsec: extend SHA-256 support in the NSS backendMiklos Vajna
With this, the xmlSecTransformIdListFindByHref() call in xmlSecTransformNodeRead() recognizes the http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 string as a valid signature method as well. Previously SHA-256 was recognized as a digest method only. Change-Id: Ib20ab97dd5bc86dff761f0c58a87afdde112e1e8
2016-01-25libxmlsec: canonize in the OOXML RelationshipTransformMiklos Vajna
This is still a skeleton, but now we canonize the incoming data, not just eat it and output nothing -> at the end we don't hit an assertion that the output of the transform chain is nothing. Change-Id: I28509b8a493c6bf6cdcbb23b95ae7de8947790c1
2016-01-25tdf#76142 libxmlsec: implement SHA-256 support in the NSS backendMiklos Vajna
This way we do not abort a signature verification when we see a <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> XML node. Note that this just extends the glue layer, both NSS and libxmlsec itself already supported SHA-256 already. Change-Id: I68de99578b839bd7eaa8f21af903aa924c892799
2016-01-25libxmlsec: recognize OOXML RelationshipTransformMiklos Vajna
The transform itself doesn't do anything so far, but the verification is no longer aborted just because we see a transform that we don't know. Change-Id: Ife89157067f3af3326896df3053065c8302795d1
2016-01-23Win build: Set default script engine for cscriptArmin Le Grand
When Windows build is executed, cscript is used to execute JavaScript files. This uses cscript from the system to execute *.js files. cscript is not only capable of executing JavaScript, but also VBScript. Which engine to run is usually determined by the file extension, except when any installed program has added a registered association to the used file type. In that case, the execution of cscript and thus the build fails. This can be prevented by directly defining the script engine when calling cscript, using the /e:javascript parameter for *.js targets. Change-Id: If717b8ae5335acbe4f11c269d3c98a7247a135e6 Reviewed-on: https://gerrit.libreoffice.org/21717 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2016-01-20libxmlsec: respect --enable-debug with GCCMiklos Vajna
So we compile using either '-O2' or '-O0 -g', instead of '-O2 -g' all the time. Change-Id: Iefc22f38be37ea876c713724657af460eb4c1606
generated by cgit (git 2.34.1) at 2025-04-29 14:51:19 +0000