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>
...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
... 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>
libxslt shared library depends on libxml2 library, and for cases when
libxml2 is "external", just-compiled libxslt will have an entry like
/@.__________________________________________________URELIB/lib/libxml2.2.dylib
and the whole LibreOffice application will fail to run
Change-Id: Ifafbdab74151207597ba9bd2e3beb0b8c3aa3ab7
Reviewed-on: https://gerrit.libreoffice.org/20816
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
- probably out of date
- links against Gtk2 and thus causes a GTk2 dependency in core packages
- the only serious usecase (Flash) is doomed anyway
Change-Id: I7264ab5eb04c2f4b6c31a815e45b9818209e5ae2
Reviewed-on: https://gerrit.libreoffice.org/20658
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Reviewed-by: Bryan Quigley <gquigs@gmail.com>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Apparently GCC 5.3.1 has turned these annoyances into actual warnings
that convert to errors with -Werror.
Change-Id: Ib1567b3fc2cf33a0f6cffac116a06d73912b84df
Don't ask.
Oh well, if you want to know: For some people, like me, Cygwin and its
Perl run into horrible trouble with the fork() emulation when building
OpenSSL. (But my Cygwin works fine for all else in the build. Go
figure.)
So I came up with a way to use prebuilt OpenSSL binaries. Not to be
used for release builds, of course (and the configury checks for
that), as long as our policy is to build all we can from sources.
Change-Id: Ic303bdf0c620c5122aca3d646fa1f0587221e70f
That's 197 more than the current release, surely a big improvement.
Change-Id: I48c81f9ae472a623ed9f59b94bb0bc921ad97c5c
Reviewed-on: https://gerrit.libreoffice.org/20303
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
This reverts commit be0bf120299cff1ec14af1b578d4ea89976cea08, which is no longer
needed after 12fc5b85ddc3b90b385ad0fc2ab0144a32bf9a4b "unnecessary include
brings in boost headers that are broken under rhel-7"
...for now; workdir/UnpackedTarball/icu/source/tools/toolutil/Makefile invokes
the compiler with a -DU_HOST=\"...\" argument, and apparently directly executes
the compiler from CreateProcess, not going via a shell invocation for the recipe
line. This confuses clang-cl for whatever reason, and for whatever other
reason, forcing make to go via a shell invocation (by adding "true &&" into the
recipe line) fixes it.
Change-Id: I3757a8856f93228c19475b37f3037fa9519a426f
* Avoid errors about (somewhat different, but apparently in a way that MSVC
doesn't care) redeclarations of system header stuff (and working around that
with BOOST_USE_WINDOWS_H would lead to other problems).
* Need the workaround for broken MSVC 2010 STL iterator taxonomy for clang-cl,
too.
Change-Id: I4f9c9b5cc8a19856cc409450aac1fb1baa5554c9
