commit 8d747b8cf8
Author: Caolán McNamara <caolanm@redhat.com>
Date: Sat Apr 29 20:01:40 2017 +0100
tweak for pdfiumless build
and lets see if
commit 6f53cf281e
Author: Markus Mohrhard <markus.mohrhard@googlemail.com>
Date: Sat Apr 29 05:11:40 2017 +0200
apparently the executable does not need pdfium directly anymore
is sufficient here
Change-Id: I2bf381e1d51d851aa829730b3d13edb1c03ea873
Initially some proof of concept code was implemented here, but then I
copied that to VCL and it got fixes there, so call into vcl from here
instead of invoking pdfium directly.
Change-Id: I8590cbe94876ff6aff3f870535a99062304f3996
Reviewed-on: https://gerrit.libreoffice.org/37016
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
The only remaining task it did was StartVerifySignatureElement() in
startElement(), but that can be done in OOXMLSecParser / XSecParser
easily, no need to have separate class for that.
Change-Id: I0863019d3a92a911df0d60bf872dd0978eac03d5
Reviewed-on: https://gerrit.libreoffice.org/36770
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Usually when the PDF file contains incremental updates the updates are
appended at the end of the document. But this is not required, the
various trailers can be in any order. Make sure that we look at the last
trailer (logically last, not the one with the largest file offset) when
looking for pages.
Change-Id: Idcd85a7c6bbf08c9436dd73933d79cdb683f482c
Reviewed-on: https://gerrit.libreoffice.org/36527
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
ImplXMLSignatureListener doesn't have to implement
XSignatureVerifyResultListener, signatureVerified() is only called at
SignatureVerifierImpl::notifyResultListener(), on an object set by
SignatureVerifierImpl::addSignatureVerifyResultListener(). But
addSignatureVerifyResultListener() is only called from
XSecController::prepareSignatureToRead() where the argument is of type
XSecController.
Change-Id: I6741e6a4ce5cf800b09189cd8b7814cd72d602ab
Reviewed-on: https://gerrit.libreoffice.org/36504
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
ImplXMLSignatureListener doesn't have to implement
XSignatureCreationResultListener, signatureCreated() is only called at
SignatureCreatorImpl::notifyResultListener(), on an object set by
SignatureCreatorImpl::addSignatureCreationResultListener(). But
addSignatureCreationResultListener() is only called from
XSecController::prepareSignatureToWrite() where the argument is of type
XSecController.
Change-Id: I378bda8b1ffdebb4305bec9eebe093aa2443b4e7
There is lots of (Windows-only) code that relied on sal_Unicode being the same
as wchar_t, and the best change may be different in each case (and doing the
changes may be somewhat error prone). So for now add SAL_U/SAL_W scaffolding
functions to sal/types.h, remove their uses one by one again, and finally drop
those functions again.
Change-Id: I2cc791bd941d089901abb5f6fc2f05fbc49e65ea
Reviewed-on: https://gerrit.libreoffice.org/36077
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The PDF code in xmlsecurity served two purposes:
- a generic PDF tokenizer
- signature verification
The first purpose is useful to have in VCL, so the PDF export code can
use it as well when it comes to PDF image handling.
This commit just moves most of the PDF code to VCL, it does not touch
the PDF export code yet. With this, also the somewhat odd xmlsecurity
dependency of CppunitTest_vcl_pdfexport can be removed as well.
Change-Id: I6fe8294ed5c4aa4d79f4b2ddef80a4d1c9d566cc
Reviewed-on: https://gerrit.libreoffice.org/35513
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Signature verification code depends on sax and xmloff, but the rest of
the PDF tokenizer could be otherwise moved down to lower layers without
problems.
Change-Id: Ieca57279e9517935821c1d34f217fd10548035ef
Reviewed-on: https://gerrit.libreoffice.org/35512
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
If the first ReadChar fails due to EOF, ch would be used uninitialized. If the
second ReadChar fails due to EOF, the SeekRel(-1) shouldn't be executed.
Change-Id: Ibf99539a3a8880a77653bd7576721104f9782e36
Reviewed-on: https://gerrit.libreoffice.org/35504
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
SAXEventKeeperImpl is the only implementation of the
css::xml::crypto::sax::XSecuritySAXEventKeeper interface, and this way
it's not necessary to cast to various interfaces explicitly at a lot of
places.
Change-Id: I25f76c88d5fefef42a6e8394a9d6de98c52b12c0
Reviewed-on: https://gerrit.libreoffice.org/35317
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Noel Grandin