Age | Commit message (Collapse) | Author |
|
Change-Id: Ice72f8d9971e15dd6ef365e64cd567b8581a92d3
Reviewed-on: https://gerrit.libreoffice.org/21797
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
|
|
Change-Id: Ic24c295a84f402ec5478bafbdebc54f976b1a72c
Reviewed-on: https://gerrit.libreoffice.org/22092
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
|
|
Note it works well on the Windows Jenkins build check. Go figure.
Change-Id: I05990274d85b1044a94ec7371130bf918f8fd09e
|
|
Change-Id: If9bf9d2a36aa564700b032c417869a8cfac65f88
|
|
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
|
|
Change-Id: If70658c568e746ab8923f8e6a5ad3407bd5e94a0
|
|
Change-Id: Ie4bf00eeaf152192d8f4fcf6b1d03d474e9d1faa
|
|
Change-Id: I9e9986ce55acaf36683244a45bc96bc76295d5c7
Reviewed-on: https://gerrit.libreoffice.org/21938
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
|
Change-Id: I4dd55a14a94e5030583f640972440fb37a7b2448
|
|
Change-Id: I9c6e55e2e09d72f6d02c985955ca84b59628ed15
Reviewed-on: https://gerrit.libreoffice.org/21903
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
|
Change-Id: I013864b9dd8baeb572b43ca7794be193a23398a3
|
|
Change-Id: I89e30eb340d84c942046a18e6f4acc7fb376def6
Reviewed-on: https://gerrit.libreoffice.org/21904
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
This reverts commit 8d5bca2a40d1fded921165cfc5637ff763b21510.
|
|
Change-Id: I651bb973bfff555b8627be85f74b49c2c6ccf425
|
|
Change-Id: Icd41e2115d30525eea26df3f92867ab6dd87c747
|
|
Change-Id: I3429f6a80dd7e080e8f2634ca744d1dac5ea1865
Reviewed-on: https://gerrit.libreoffice.org/21558
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
|
|
With this, SfxObjectShell_Impl::showBrokenSignatureWarning() is no
longer triggered for the SHA-256 bugdoc.
Change-Id: I7a2c5c8517c757e2983f57a3a5908abb941e7a04
|
|
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
|
|
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>
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
Seems to cause tinderbox build breakage, sigh.
This reverts commit 1c1b788f38da07aed268be3c515a096594a107dc.
Change-Id: I5a69e186e0f8f71c2fcc81d27bebe2253fd240bb
Reviewed-on: https://gerrit.libreoffice.org/21699
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: Id9b4873b8213d9913d54b3821ba0be6ffa7ac188
Reviewed-on: https://gerrit.libreoffice.org/21612
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
...which choke on
#pragma GCC diagnostic ignored "-Wpragmas"
Change-Id: I40100b43078320b79cb9e3d4e3fb369db0bed9fe
|
|
So we compile using either '-O2' or '-O0 -g', instead of '-O2 -g' all
the time.
Change-Id: Iefc22f38be37ea876c713724657af460eb4c1606
|
|
Change-Id: I3babe33ab5be1c3521ccb8bee71239e3d8893a2f
|
|
...which switched defaults from C++03 to C++14, so causes some errors now.
Curiously, the throw(std::bad_alloc) vs. throw-anything mismatch between the
global operator new replacements and the standard headers is OK for GCC only
when there is no further declaration in between the standard header and the
replacmenet definition.
Change-Id: Ib54727fecf4ad07426b811a9cc04b08ea80e59dc
|
|
Change-Id: If726008f6755db59b01784ad6b479bbfe2d23e96
|
|
Change-Id: I9b1aa86e3cb325b07158e3994a961db8ea4114d8
|
|
...and would thus error out with -Werror=pragmas?
Change-Id: I113c43bed4d6d0c03e4c3c68684c50fd386428d9
|
|
Change-Id: I60f7817b1d5e32ad642076ea2a9f7b7522ebb1de
|
|
Change-Id: I9a067605f7c477f4e057338577a437cda7f2aa3d
|
|
Change-Id: I4613f013c39e439dd11d3abc3737511cb8788d4f
|
|
Seems to break the tinderbox, needs more work?
This reverts commit 6aaf1ec5a781b50ceda6d0d288a43dba435be2ce.
|
|
Change-Id: I2d4cedac4081260c5147d8c11904d042c765e3a6
Reviewed-on: https://gerrit.libreoffice.org/21557
Tested-by: Jenkins <ci@libreoffice.org>
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I3ae138d1a06d22be42a3cd6f565fba6950208fc6
|
|
Change-Id: Ifde1184e469fc9a74de007a0caf27750b2ffbcbb
|
|
Change-Id: Ia1cbb24f8c579d1b3b7fe0e916318c8f6fa9430f
|
|
Change-Id: I9a5940027423ff0791fa7da0b79b617412ce6b86
Reviewed-on: https://gerrit.libreoffice.org/21209
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
|
|
Change-Id: Ib897e5fa5e80f75f501694dbf874aabd92253b25
Reviewed-on: https://gerrit.libreoffice.org/21247
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Martin Hosken <martin_hosken@sil.org>
|
|
... to avoid calling C:/Windows/system32/{sort,find}.exe, if those
happen to be first in PATH.
On a Windows 7 system, the other conflicts appear to be harmless,
we don't use "more", "expand", "timeout", "whoami".
Change-Id: Iceefeb7ee6725291b04c0eba465991bb1df96b57
Reviewed-on: https://gerrit.libreoffice.org/21175
Tested-by: Jenkins <ci@libreoffice.org>
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: If43ca99631fab5a3a04e7dead9b694cf52944666
Reviewed-on: https://gerrit.libreoffice.org/20882
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Iec71ad4918cd333f0a44d372017ecee300e3aca9
Reviewed-on: https://gerrit.libreoffice.org/20748
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Martin Hosken <martin_hosken@sil.org>
|
|
Change-Id: Ic77d0510801f3655d914aea0e8ce66476853358a
|
|
Change-Id: Iba35a273230c96914d527475a8cefcbfab14c341
|
|
Change-Id: Ia86ebe7cd48de3f42dd95a11be7926f1e83d9113
|
|
Change-Id: I27f8039f65777c37ce8191f37dc3daa8728667dd
|