summaryrefslogtreecommitdiff
path: root/external/libxmlsec
AgeCommit message (Collapse)Author
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
2015-09-04Fix libxmlsec on MSVC 14.0David Ostrovsky
Change-Id: I37fd06bb0df1ad8f23eddc32b8eb5c93b2943fda Reviewed-on: https://gerrit.libreoffice.org/18327 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Ostrovsky <david@ostrovsky.org>
2014-11-28Fold URE: Linux ure/lib/* -> program/Stephan Bergmann
The ../../../program/ links in the URE jar Class-Paths are a temporary kludge (and juh.jar had lacked adaption for Mac OS X). Change-Id: I2542d8a582866485dd61c05df3fc6b4b39a8403d
2014-10-02fdo#82430: MSVC build: avoid using SSE2 instructions in some externalsMichael Stahl
Hopefully this should fix up the most important external libraries. Change-Id: I744cb5a2ce7fafb10852059050cf24589d6ca400
2014-08-12Now that we build NSS, we can build libxmlsec and libxsec_xmlsec for iOS, tooTor Lillqvist
Change-Id: I65ab8aad0744a2aa254fefc7732cd8130bb249fb
2014-07-20fdo#63756 build libxml2 with ICU supportDavid Tardon
Change-Id: I0523e49e640812be435ba4c97b1881ca253eb2ab
2014-05-13update libxmlsec config.* to support ppc64leDavid Tardon
Change-Id: I4b31729481b7fd538483db5b6e39e1d80e03b3b6
2014-03-11normalize values of MINGW_SHARED_GCCLIB/MINGW_SHARED_GXXLIBMichael Stahl
Change-Id: I4f4cecd95f87b9d37fa1b1a270cf554d7707aaa2
2014-02-27normalize values of CROSS_COMPILINGMichael Stahl
Change-Id: I0cc43cef91e3fcd82a3558a16ab0afbd4d56b141
2014-02-12normalize values of SYSTEM_FREETYPE, SYSTEM_LIBXML, SYSTEM_MARIADBMichael Stahl
Change-Id: Iffcc671ca41c5880579effe0786a3b4d3be0dab0
2014-02-12fdo#74825: fix missing lcms2/libxslt/curl in installation setsMichael Stahl
The assumption that all configure variables had been normalized to TRUE/<empty> turned out not to hold; convert a bit more in that direction. (regression from 4af38b099c741c3676aefeb20c515913aaeed666) Change-Id: I2127c515e8a833a07c9b26ed9d693ce5a1853fe4
2014-01-10libxmlsec: openssl conditional was accidentally invertedMichael Stahl
... in commit bf6d1f77420dcc9ece4d9f4eae1e37b427d85c6a. And it just happens to not build with clang here. Change-Id: Ic467abc894b9c98c81fa64cb57eafaa4cfcaa66e
2013-11-14nss: upgrade to 3.15.3Michael Stahl
- from nss_macosx.patch drop nmedit hunk (removed upstream) - adapt include and lib paths to changed tarball directory layout Change-Id: Ia5dcce8dfd9d10e7e4ba689eefa9f39a51596dfe Reviewed-on: https://gerrit.libreoffice.org/6670 Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2013-11-04fdo#70393: move libxmlsec to a subdir of externalKhaled Hosny
Change-Id: I1bcdd01aad7fc2ee2d2f635b0ae4c4183c9ab092 Reviewed-on: https://gerrit.libreoffice.org/6571 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
generated by cgit (git 2.34.1) at 2025-01-06 10:19:18 +0000