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>
Even though SignedData.digestAlgorithms is mandatory in CMS,
the set can be empty. One ends up with a valid list containing
a single nullptr. According to RFC 5652, one MAY reject signatures
without signedData.digestAlgorithms.
SignedData.certificates is OPTIONAL in CMS. If omitted, one gets
nullptr instead of a list of entries. Rejecting such signatures
is apparently OK for adbe.pkcs7.detached and required for
ETSI.CAdES.detached.
Change-Id: If0270bd3f2d4312947562ab68d2206ae47370b06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185540
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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
Have electronic signing configured in the LOK client, try to insert a
signature line, you'll get a certificate picker, while we don't have a
cert during esign.
What's in fact needed for creating the signature line is just a name
(previously extracted from the certificate), we can survive the lack of
actual certificate.
Fix the problem by adding a new External parameter to
.uno:InsertSignatureLine to hint that the certificate chooser should not
be opened, instead the editor name (used for comments already) should be
used. Add a new CertificateOrName in svl/ and use that in all places
where previously we wanted a certificate but in fact it's enough to have
a certificate or a name to create the signature line.
The name on the signature line is just visual feedback, the actual name
on the crypto signature is still not based on untrusted used input.
Change-Id: Ib7008112a8e28a9e7d9649745e6021dd6b6b9c39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180193
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
xmlsecurity/qa/xmlsec/xmlsec.cxx:102:(anonymous namespace)::testInsertPrivateKey::TestBody
equality assertion failed
- Expected: 1
- Actual : 0
Just copying the NSS setup code from the other tests lets the test pass.
Also sync all the copies of the setup code while at it.
Change-Id: Idcaebec4dff29f37e0ed0f05d6d7d62782947325
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179893
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
testDropMacroTemplateSignature fails printing this:
warn:xmlsecurity.xmlsec:3511616:3511616:xmlsecurity/source/xmlsec/errorcallback.cxx:53: signatures.c:599: xmlSecNssSignatureSetKey() 'rsa-sha1' 'VFY_CreateContext' 4 'NSS error: -8011'
because policy sets NSS_RSA_MIN_KEY_SIZE to 2048.
testPDFGood fails printing this:
warn:svl.crypto:3587940:3587940:svl/source/crypto/cryptosign.cxx:1941: ValidateSignature: message is not signed
warn:xmlsecurity.helper:3587940:3587940:xmlsecurity/source/helper/pdfsignaturehelper.cxx:482: failed to determine digest match
because enabling SEC_OID_SHA1 for NSS_USE_ALG_IN_ANY_SIGNATURE doesn't
enable it for SMIME signatures, so smime_allowed_by_policy() fails -
obviously one has to use NSS_USE_ALG_IN_SIGNATURE to enable it in any
signature.
Change-Id: I59ffaf0994eee6b51362fd3296f61465d0fc7903
(cherry picked from commit a7b7b00b78426bff8607c77106ea62dd213f0821)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178663
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
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
The trouble with signing via ca/cert/key PEM files is that usually the
CA is not trusted by the received of the signature. 3rd-party services
are available to do generate trusted signatures, but then you need to
share your document with them, which can be also problematic.
A middle-ground here is to sign the hash of the document by a 3rd-party,
something that's supported by e.g.
<https://docs.eideasy.com/electronic-signatures/api-flow-with-file-hashes-pdf.html>
(which itself aggregates a number of providers).
As a first step, add LOK API to get what would be the signature time
during signing -- but instead of actually signing, just return this
information. Once the same is done with the doc hash, this is supposed
to provide the same info than what the reference
<https://github.com/eideasy/eideasy-external-pades-digital-signatures>
app does.
This is only a start: incrementally replace XCertificate with
SignatureContext, which allows aborting the signing right before calling
into NSS, and also later it'll allow injecting the PKCS#7 object we get
from the 3rd-party.
Change-Id: I108564f047fdb4fb796240c7d18a584cd9044313
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176279
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
These are only sent to an external API expecting char*-like strings,
or for comparison. Having every assertXPath having three of _[ou]str
is too much syntactic noise, making the unit tests almost unreadable.
Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
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
testPDFAddVisibleSignature was failing for me locally because of
an expired certificate present in my store.
Change-Id: I03243f6707b1b5ca94ea87e9f8c809dd47b6a93a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171901
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The problem was that running UITest_xmlsecurity_gpg changed the files in
test/signing-keys/ ... prevent that by copying the directory in that
test, which is more complicated than initially expected.
Change-Id: Ie3be922e0b2e9dae49f9a70e35ad5270c90b4fc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171322
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
The new tests fail with:
> core/xmlsecurity/qa/unit/signing/signing2.cxx:
> 252: Assertion
> Test name: testPasswordPreserveMacroSignatureODFWholesomeLO242::TestBody
> equality assertion failed
> - Expected: 1
> - Actual : 4
This is because only the first test that runs sees the testing CA
certificates that are copied in MacrosTest::setUpNssGpg(); when the
second test runs, they have somehow vanished.
This is because apparently SQLite on MacOSX, unlike on Linux, monitors
the file descriptors of its database files, and then invalidates itself
when setUpNssGpg() via osl::File::copy() renames and unlinks the
existing database files:
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode renamed while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/cert9.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 5 (0x20)
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode unlinked while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/cert9.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 5 (0x11)
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode renamed while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/key4.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 6 (0x20)
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode unlinked while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/key4.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 6 (0x11)
Split MacrosTest::setUpNssGpg()/tearDownNssGpg() into functions
setUpX509() which only does something on the 1st invocation, and
setUpGpg()/tearDownGpg() which may be invoked per-test (they could also
be run once for the whole test suite, but not obvious how to do that);
PDF related tests don't need GPG.
Presumably this is (along with the WNT-specific problem fixed in commit
3e9a700091) the reason why most of the
tests not only accept the expected result of SignatureState::OK but also
SignatureState::NOTVALIDATED.
Change-Id: I59b85ca651cecaccfdea729ed1e645c53079c8bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162693
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The old name was misleading (it doesn't take an URL, but a filename);
also, now it's easier to grep for it - doesn't get mixed with
vcl::graphic::loadFromURL.
Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...now that warning about O[U]String vars that could be O[U]StringLiteral is no
longer useful
Change-Id: I389e72038171f28482049b41f6224257dd11f452
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157992
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This is particularly useful for a Writer document that contains a
section that is set to be editable in a read-only document, so that the
user is warned when closing such a document without saving it.
Originally this check was added in commit
27db57efc5 "CWS fwkbugfix05"
"#i39869#: readonly docs should never become modified"
but the actual problem there was that the read-only document was
displayed in a wizard dialog, not in a document view, so let's instead
check that the document is some kind of "internal" document.
Also the dialog's Save button should do something, and since the
document is read-only, a Save As dialog appears appropriate.
Change-Id: I339cbe92a2c9eb74a1f5061246f921037a47f79c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153180
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Xisco Fauli