stage 2 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
In this stage we focus on replacing usage of the WIN macro
Change-Id: Ie8a4a63198a6de96bd158ecd707dadafb9c8ea84
Reviewed-on: https://gerrit.libreoffice.org/22393
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Fails when the relevant part of XSecController::exportOOXMLSignature()
is commented out, i.e. the member function just writes a <Signature> XML
element, no child elements.
Change-Id: I526c1170c8ada71f111a1ad56d74af1a4102dbce
Reviewed-on: https://gerrit.libreoffice.org/22375
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
This wasn't a problem when we signed MSO-produced documents that have
these all the time, but it was a problem for LO-produced documents.
We don't add an explicit content type for _xmlsignatures/origin.sigs, so
need a default for the .sigs extension.
Change-Id: Ic5d0647991c42f9f1ef3519986a4bd1b56de396d
Another redundant field: it's the SHA-256 digest of the certificate data
for OOXML, not used for ODF. We need to store it after import, as we no
longer have the security environment at hand when we store the signature
to the persistent storage.
Change-Id: I3bcccb3c7c4f4178c0b267ce87777fba543f8716
OOXML export will need an SHA-256 hash of the certificate, introducing
a css::security::XCertificate2 just for this would be probably an
overkill. The same will have to be done in the mscrypto backend in the
near future.
Change-Id: Id2df06416a713927edd60e1253ff8e1c09dd706a
This is redundant, but it's needed to survive an export -> import ->
export flow, and at the end required in the OOXML result.
Change-Id: I0779950b6464b4e15f4da452c163cddbc3d03a3d
Our own importer is happy about the export result already, but MSO is
more picky, and mandates the correct content types for both
_xmlsignatures/origin.sigs and the individual signature streams.
With this, MSO can open the signed file again (while previously it just
declared the file corrupted), though it still declares the signature
invalid.
Change-Id: I199ad96bb91e7ce03fdf1f10f9500db4e05bb5c1
The problem was that the final export lacked the "#" prefix in the
same-document reference names. Fix this by doing what the ODF export
does: don't let the signature informations (data model) contain the "#",
just prepend it right before writing the name out.
This way it won't matter if the source of the name is an import (which
doesn't keep the "#") or a new signature (which did, previously), we'll
always write exactly one "#".
Change-Id: I18b6a5ba55b7e79ace537b7ecf575a7abc71e281
The root cause (and that still needs fixing) is that the OOXML signature
export fails to start same-document references with a "#" character.
OTOH, even if that happens, it's better to throw uno::RuntimeException
in UriBindingHelper::OpenInputStream() to avoid std::terminate().
Change-Id: I9c9c211de36fb0aeb2c33f62b094c9f4d9c85b3d
With this, _xmlsignatures/_rels/origin.sigs.rels and
_xmlsignatures/origin.sigs is written to the destination file.
Change-Id: I8d63a182e7cf05ed20195f88c90fba2a9a05379e
Previously this code worked only for reading, as we assumed if it
doesn't exist, then the storage is not OOXML, either.
With this, DigitalSignaturesDialog::OKButtonHdl() gets a valid storage,
where it'll be able to write the actual signatures.
Change-Id: Iadf63a88c962386abc31225c02398761aea818cb
When reading a signature, we just take the ODF signature stream or OOXML
signature storage.
When writing, we write to an ODF temporary stream / OOXML temporary
storage, read it back, and only the signatures dialog close handler
writes the signature back to the original file.
The underlying OOXML temporary storage's stream is the signature stream,
so only try to load signatures from the stream if it's not OOXML,
throwing a ZIP file at an XML parser is not a great idea.
Change-Id: I6e42d117b9c97676aaeaad158e78e39a2c39a5e8
The usual generator/meta stream and the signatures itself are the
excluded ones. It seems everything else has to be listed explicitly.
Change-Id: Ie0f3e161aa0c2e1cb97ad3d9d012ac78078e287a
In ODF, they're relative to the package root, in OOXML they always start
with a leading slash.
Also, in OOXML the stream URI should have its content type as the
suffix.
Change-Id: Iac570ed15533a23c8a6098f99b716f90e1bac0e0
If the signature refers to an XML element with that id, we must export
at least a stub, otherwise xmlSecDSigCtxSign() will refuse to do
anything with the signature template.
With this, at least some calculated hashes and signature values appear
in the OOXML output.
Change-Id: Iff26c6ae0b97bf3509144a66a2c23070100a5974
So that we pass the correct node to xmlSecDSigCtxSign().
SAXEventKeeperImpl::startElement() always marks the first node written
by XSecController, which is the Signature node for ODF, but for OOXML,
the Signature node is the root element.
Fix the problem by writing the root element in
XSecController::exportOOXMLSignature() instead of doing it earlier,
similar how it's done for ODF (where we intentionally want to not mark
the root node).
Change-Id: Id0a76f155726ad53a996e9327454b8795497ac7b
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
They are kind of a special case for ODF, but OOXML uses these
exclusively, and then one of them refers to the actual package streams.
Change-Id: I4663eef4bd718a7563effd6cafa790126db6d8c7
Having them in the file apptypes.hxx isn't necessary helpful, IMO so
I've split the types into inputtypes.hxx and exceptiontypes.hxx
Change-Id: I89a1ff168c3ae276b2f5486669d4ec2dda062d57
_rels/origin.sigs.rels of the _xmlsignatures temporary storage now
contains references to the individual signature streams.
Change-Id: I619bd81989e3b62fc4282e0e72fbfa780d1fb8bd
Stephan Bergmann