The package supporting the “pdfium” library has been improved.
Numeric values have been converted to a fixed-size enumeration type.
The changes apply to all occurrences of the older version of this code.
Change-Id: Ie9d0bd98d7c323f890ac3051bb1f08a50d51e046
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201303
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Found after running bin/find-unneeded-includes --headersfwd include/vcl/[d-g]*
This shaves off about 150M input
Change-Id: I2b15257451d4b392dca3e5d07f4a443ee653b04c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196395
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
Converted plain enums to enum class for better type safety:
- xmlreader: Converted two local Space enums to enum class and removed
redundant SPACE_ prefix from enum values (NONE, SPAN, BREAK, START)
- xmlsecurity: Converted EqualMode enum to enum class
- xmlsecurity: Converted local State enum in CompatDNCryptoAPI to enum class
Updated all usages across 8 files to use scoped enum syntax.
Change-Id: I27fd7280bccad72a43cda3b669b1f0926c34271c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196207
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
utl::MediaDescriptor was just a SequenceAsHashMap with a few added
methods. It made it more difficult to assign a SequenceAsHashMap to
MediaDescriptor, without real upsides. In many places, the class was
used not as media descriptor, but just as helper to create sequences.
This change puts the string constants and the former methods into a
namespace utl::MediaDescriptor.
It would be also good to drop comphelper::NamedValueCollection, which
is basically a twin of comphelper::SequenceAsHashMap (TODO).
Change-Id: Ia9b69c5a2ad153ecc654944c419c1880252ed86e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195163
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
and
cid#1659754 Variable copied when it could be moved
cid#1659755 Variable copied when it could be moved
cid#1659756 Variable copied when it could be moved
cid#1659766 Variable copied when it could be moved
cid#1659767 Variable copied when it could be moved
cid#1659769 Variable copied when it could be moved
cid#1659770 Variable copied when it could be moved
cid#1659777 Variable copied when it could be moved
cid#1659787 Variable copied when it could be moved
cid#1659790 Variable copied when it could be moved
cid#1659793 Variable copied when it could be moved
cid#1659802 Variable copied when it could be moved
cid#1659818 Variable copied when it could be moved
cid#1659822 Variable copied when it could be moved
cid#1659824 Variable copied when it could be moved
cid#1659825 Variable copied when it could be moved
cid#1659826 Variable copied when it could be moved
cid#1659842 Variable copied when it could be moved
cid#1659849 Variable copied when it could be moved
cid#1659850 Variable copied when it could be moved
Change-Id: I70729aaf6e229518a9a50ac18311286ab5b05b53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189348
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
and
cid#1660225 Variable copied when it could be moved
cid#1660211 Variable copied when it could be moved
cid#1660185 Variable copied when it could be moved
cid#1660173 Variable copied when it could be moved
cid#1660168 Variable copied when it could be moved
cid#1660166 Variable copied when it could be moved
cid#1660165 Variable copied when it could be moved
cid#1660163 Variable copied when it could be moved
cid#1660152 Variable copied when it could be moved
cid#1660149 Variable copied when it could be moved
cid#1660147 Variable copied when it could be moved
cid#1660145 Variable copied when it could be moved
cid#1660142 Variable copied when it could be moved
cid#1660140 Variable copied when it could be moved
cid#1660137 Variable copied when it could be moved
cid#1660136 Variable copied when it could be moved
cid#1660135 Variable copied when it could be moved
cid#1660128 Variable copied when it could be moved
cid#1660124 Variable copied when it could be moved
cid#1660122 Variable copied when it could be moved
cid#1660117 Variable copied when it could be moved
cid#1660114 Variable copied when it could be moved
cid#1660110 Variable copied when it could be moved
cid#1660109 Variable copied when it could be moved
cid#1660105 Variable copied when it could be moved
cid#1660104 Variable copied when it could be moved
cid#1660102 Variable copied when it could be moved
cid#1660100 Variable copied when it could be moved
cid#1660098 Variable copied when it could be moved
cid#1660080 Variable copied when it could be moved
cid#1660079 Variable copied when it could be moved
cid#1660078 Variable copied when it could be moved
cid#1660075 Variable copied when it could be moved
cid#1660071 Variable copied when it could be moved
cid#1660070 Variable copied when it could be moved
cid#1660064 Variable copied when it could be moved
cid#1660063 Variable copied when it could be moved
cid#1660060 Variable copied when it could be moved
cid#1660058 Variable copied when it could be moved
cid#1660053 Variable copied when it could be moved
cid#1660050 Variable copied when it could be moved
cid#1660049 Variable copied when it could be moved
cid#1660046 Variable copied when it could be moved
cid#1660042 Variable copied when it could be moved
cid#1660028 Variable copied when it could be moved
cid#1660023 Variable copied when it could be moved
cid#1660022 Variable copied when it could be moved
cid#1660021 Variable copied when it could be moved
cid#1660020 Variable copied when it could be moved
cid#1660017 Variable copied when it could be moved
cid#1660013 Variable copied when it could be moved
cid#1660005 Variable copied when it could be moved
cid#1660003 Variable copied when it could be moved
cid#1659999 Variable copied when it could be moved
cid#1659998 Variable copied when it could be moved
cid#1659995 Variable copied when it could be moved
cid#1659993 Variable copied when it could be moved
cid#1659989 Variable copied when it could be moved
cid#1659988 Variable copied when it could be moved
Change-Id: I2a30c8a2ac8785050d49b98635b0b406535b185a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189056
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
and
cid#1660211 Variable copied when it could be moved
cid#1660204 Variable copied when it could be moved
cid#1660195 Variable copied when it could be moved
cid#1660194 Variable copied when it could be moved
cid#1660193 Variable copied when it could be moved
cid#1660191 Variable copied when it could be moved
cid#1660188 Variable copied when it could be moved
cid#1660187 Variable copied when it could be moved
Change-Id: Ifcb179f73723e2d43144e242fa9c1b5ac332cd4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188965
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
and
cid#1660283 Variable copied when it could be moved
cid#1660278 Variable copied when it could be moved
cid#1660277 Variable copied when it could be moved
cid#1660272 Variable copied when it could be moved
cid#1660271 Variable copied when it could be moved
cid#1660269 Variable copied when it could be moved
cid#1660257 Variable copied when it could be moved
cid#1660251 Variable copied when it could be moved
Change-Id: I6684eaf2162dd3550e2eab3f72cccbaa09448f43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188925
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
and
cid#1660326 Variable copied when it could be moved
cid#1660325 Variable copied when it could be moved
cid#1660324 Variable copied when it could be moved
cid#1660321 Variable copied when it could be moved
cid#1660320 Variable copied when it could be moved
cid#1660316 Variable copied when it could be moved
cid#1660313 Variable copied when it could be moved
cid#1660307 Variable copied when it could be moved
Change-Id: I9fe4fa56693f8e3a1efd47294ecb7e0e5588b9b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188851
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
and
cid#1660421 Variable copied when it could be moved
cid#1660419 Variable copied when it could be moved
cid#1660416 Variable copied when it could be moved
cid#1660406 Variable copied when it could be moved
cid#1660405 Variable copied when it could be moved
cid#1660403 Variable copied when it could be moved
cid#1660388 Variable copied when it could be moved
cid#1660380 Variable copied when it could be moved
Change-Id: Ic017abb85bb9b3f9fdb962c0862476f40c0953f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188847
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
and
cid#1659624 Variable copied when it could be moved
cid#1659632 Variable copied when it could be moved
cid#1659637 Variable copied when it could be moved
cid#1659656 Variable copied when it could be moved
cid#1659662 Variable copied when it could be moved
Change-Id: I20179a4ff699af546694b8a4796ab2f0cfae1903
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188708
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
No functional changes intended:
- Replace SfxObjectShell::GetSignPDFCertificate() and
SfxObjectShell::ResetSignPDFCertificate() with
SfxViewShell::SetSignPDFCertificate() and
SfxViewShell::GetSignPDFCertificate(), because information about shape
selection belongs to the view.
- Change svx::SignatureLineHelper::setShapeCertificate() to use
SfxViewShell::SetSignPDFCertificate() to avoid duplication.
- Change GetSignatureLineShape() in xmlsecurity/ to use
SfxViewShell::GetSignPDFCertificate(), again to avoid duplication.
With this, all setters/getters of the inserted signature line go via
SfxViewShell and the amount of getCurrentSelection() calls on the model
is reduced.
Change-Id: I021bc41262b2a16d1014fbf1431a0eb6e1e86c73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180355
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The final goal of this API is to give time & hash information about the
PDF signature, so once a 3rd-party produces the PKCS#7 signature, that
can be added to the document and the actual PDF sign can be re-run with
the same parameters.
This commit continues the replacement of XCertificate with
svl::crypto::SigningContext up to the point that the timestamp used in
svl/ can be exposed on the LOK API.
This is done by updating DocumentSignatureManager::add(),
PDFSignatureHelper::SetX509Certificate(),
vcl::filter::PDFDocument::Sign() and finally the svl::crypto::Signing
ctor to work with the signing context instead of an XCertificate
directly.
Time reporting works now, so add a test for that. The digest part still
needs doing.
Change-Id: I83f1274cd420b67194b7caf12b1027e623d4f7fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176404
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Some functions were already a stub and only aborted on calling them.
The *Package* functions were added in commit
c9ed2f359a (INTEGRATION: CWS xmlsec08
(1.4.24); FILE MERGED 2005/02/22 13:07:19 mt 1.4.24.1: #i36682# Accept
separate Stream for signatures..., 2005-03-10), but it seems nobody
called them.
This also means that DocumentSignatureMode is now never set to
DocumentSignatureMode::Package, so remove that as well.
It seems to be unlikely that this non-published service was used by
3rd-party code, since it was specific to the needs of sfx2/ code, not
generic functionality that could be useful in other contexts.
Change-Id: Icfed9a0e6568f6eb21f9236901af01f1915bf2f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173313
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Sign a document with macros (via file -> digital signatures -> digital
signatures), realize that you still get a warning on file open, sign the
macros in the document (via tools -> macros -> digital signature),
realize that you did this in the wrong order, so now you have to re-sign
the doc content.
The reason for this is that the macro signature only signs the macro
parts of the document (so you can still edit the document and the
signature is valid, as long as you don't touch macros), while the doc
content signature signs everything, including the macro signature, so
the order of the two matters.
Solve this trouble by adding a new setting that allows doing the two
signatures in one step. Do this by extending the doc content signing
code with an optional pre-step that first signs the document macros.
This is a bit tricky to do, since xmlsecurity/ gets an RW signature
stream and a RO document storage from sfx2/, but transferring one more
signature stream can solve this trouble.
Other tricky parts of the change:
1) The crypto signing is always done by libxmlsec, so
DigitalSignaturesDialog::SetScriptingSignatureStream() has to update
the storage of the sign manager's sign helper, otherwise, the hashes in
the macro signature will be empty.
2) Signing reads the RO storage, so normally the macro signature
would not be part of the doc signature when creating both signatures
inside a single dialog. (The storage is only committed after the
dialog ends.) Fix this problem by extending
DocumentSignatureManager::add() and UriBindingHelper::OpenInputStream()
to provide kind of an overlay when xmlsecurity/ gets a script signature
stream: this way the macro signature will be part of the doc signature
while the dialog is in progress. No overlay is needed later, once both
streams are committed to the storage on dialog end.
Change-Id: Ic2728689997165595991d5ec59c7a2683286e22d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173263
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Currently SfxObjectShell::CheckIsReadonly() has a hack for the LOK case
to show the signatures dialog read-only, as only that is async.
The next step is to make DocumentDigitalSignatures::ImplViewSignatures()
async, though that requires all callers of the function to be async, so
make DocumentDigitalSignatures::signScriptingContent() async as well.
There is also DocumentDigitalSignatures::signPackage(), but turns out
that's dead code, so just remove it.
Once this is in place, we had a problem that the callbacks tried to
interact with libxmlsec, but the dialog was still alive in
DocumentDigitalSignatures::ImplViewSignatures() by the time the callback
was running, so there were two DocumentSignatureManager instances at the
same time, and both assumes it should call the global libxmlsec
init/uninit, which resulted in failing to verify the just created
signature.
Fix this similar to how Tomaz fixed the same problem around pdfium in
commit 067a8a954c (pdfium: only init
pdfium library one and destroy on LO exit, 2020-06-03).
Change-Id: I3fb63c06195564732e1576dbd755157e676fb762
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173117
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Commit 4d6e9d5e15 added 2 tests that
always fail on WNT, unfortunately Jenkins doesn't actually run the
tests.
There are 3 certificates involved:
"Xmlsecurity RSA Test Root CA"
"Xmlsecurity Intermediate Root CA"
"Xmlsecurity RSA Test example Alice"
In the signature XML, there are 3 elements that contain or reference
certificates:
1. X509Data - xmlsecurity produces only the signing certificate here
2. xd:SigningCertificate (XAdES) - again only the signing certificate
3. xd:EncapsulatedX509Certificate (XAdES) - xmlsecurity produces the
full certificate chain here
All of these elements *could* contain the full certificate chain, but in
LO-produced XML signatures only 3. does.
The problem is that the function CheckUnitTestStore() that looks up
a certificate in a unit-test-specific CA store via
$LIBO_TEST_CRYPTOAPI_PKCS7 can only handle a root certificate, it does
not recursively retrieve and check a certificate chain.
The SecurityEnvironment_MSCryptImpl::verifyCertificate() already has a
parameter "seqCerts" to pass in the full certificate chain, but due to
the way the data from the XML is processed, it gets passed only the
content of the X509Data element(s), which, for LO-produced signatures,
do not contain the full certificate chain.
Instead of improving the unit-test-specific function, let's try to get
all the certificates out of the XML signature, and then pass them to
verifyCertificate().
Of course this requires some consistency checks so that the verification
can't be fooled by different certificates in different XML elements.
Change-Id: I8ca541887ceac2dfb6af5d96a5565cfa58d7f682
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162170
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
OUStringLiteral should be declared constexpr, to enforce
that it is initialised at compile-time and not runtime.
This seems to make a different at least on Visual Studio
Change-Id: I1698f5fa22ddb480347c2f4d444530c2e0e88d92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153499
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
And simplify the latter, to always use "CDATA" type (as the former did).
"CDATA" was used in all cases but one, where an empty string was used.
Change-Id: I1b3bfae40e29628e4094d9a6e58a69a66865874c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145526
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I3d9bd77093d2e6376717d27f105e72ff5a919fe7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144696
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I3c2f1eae3d9b2b5ecb6a05c9e7149946b63bb11f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144697
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
And use an overloaded helper function with a better (?) unified name
to show that the result is not an O(U)String.
Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Regression from commit 78e25558e8
(tdf#106059 PDF export: create a reference XObject for JPG images with
PDF data, 2017-02-23), once a PDF image was inserted to a document, an
encrypted PDF export lost those images.
The reason for this is that we started to preserve PDF images as vector
data with the above commit, but this means we copied over PDF objects
from PDF images to the export result as-is, so encryption was not
performed for them.
Fix this by separating the write of the PDF object headers, stream
content and object footer and then calling
checkAndEnableStreamEncryption() / disableStreamEncryption() for each
object, even if it's not something our PDF export created but comes from
a PDF image.
Note that when existing PDF files are signed, PDF objects are also
copied into a vcl::filter::PDFDocument, but such PDF images are never
encrypted, so it's fine to have stub implementations in
vcl::filter::PDFDocument.
Change-Id: I2f74b9f51cd35b4319221532ca890e197bab9cf3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137242
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
If we are not going to manipulate the resulting vector, then it is
actually slower, since we have to allocate more storage for the vector
Change-Id: I65677007d105f4783603df74113ebed6db0b551b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133963
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Rafał Dobrakowski