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>
I have a case where LOK convert-to with ODT->PDF and
SignCertificateCaPem/SignCertificateCertPem/SignCertificateKeyPem set
creates a corrupted PDF signature, while more or less the same on the
desktop works.
The PDF signature is a hex dump, and once converted to binary, one can
analyze the content using 'openssl asn1parse -inform der -in ... -i'.
Still, the LOK and the desktop case differs, because this script
generates random certificates and then the binary output in the two
cases differs, so hard to see the actual difference.
Fix the problem by still generating .p12 output (needed for the desktop
case) in the no-password case, so a single run can emit ca/cert/key PEM
files and a .p12 archive, so exactly the same input can be used for
desktop and LOK signing.
It turns out the actual problem I looked at was some setup problem,
because now that the same input can be used in the two cases, the LOK
signing during PDF export works fine.
Change-Id: Ifc5ff73cd6fbbc057af536c84e4367ce1d489931
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176081
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
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
Once the signing key is taken from the matching SfxViewShell (not yet
done), signing with a certificate specified via initializeForRendering()
failed with:
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/nss/x509certificate_nssimpl.cxx:330: X509Certificate_NssImpl::getPrivateKey() cannot find private key
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/nss/securityenvironment_nssimpl.cxx:812: Can't get the private key from the certificate.
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: keys.c:1347: xmlSecKeysMngrGetKey() '' '' 45 'details=NULL'
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: xmldsig.c:822: xmlSecDSigCtxProcessKeyInfoNode() '' '' 45 'details=NULL'
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: xmldsig.c:537: xmlSecDSigCtxProcessSignatureNode() '' 'xmlSecDSigCtxProcessKeyInfoNode' 1 ' '
warn:xmlsecurity.xmlsec:13020:13005:xmlsecurity/source/xmlsec/errorcallback.cxx:53: xmldsig.c:301: xmlSecDSigCtxSign() '' 'xmlSecDSigCtxProcessSignatureNode' 1 ' '
The trouble was that we wanted to keep the private key in-memory,
presumably because initially the whole NSS database was in-memory for
the LOK case. This was changed in commit
87eec1b90b (NSS: create a temporary
database instead of in-memory, 2018-12-31), so there is no problem with
a not-in-memory private key anymore.
Note that the problematic codepath was only triggered when first the
certificate chooser was ran and only then we signed. So the testcase
also gets the cert flags before signing, otherwise the test would
succeed even without the fix.
Change-Id: I5086b205c91b630ddd343c0eb91bd9e63b3ea238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173892
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Now one can use './create-certs.sh RSA NOPASS' to create signing certs
without encrypting them with a password. This is meant to be useful for
the case when these certs have to be imported using the LOK API, and not
interactively in Firefox, where one could ask for a password.
Change-Id: I4cfc49ac8ff8c2420baa943b553a7a180a71e3bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173651
Reviewed-by: Miklos Vajna <vmiklos@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>
fix GPG CertificateImpl::getSHA1Thumbprint not returning a
sequence of bytes as the thumbprint. (that is what the
documented API states, and what all of the code assumed.)
now /org.openoffice.UserProfile/Data/signingkey and
encryptionkey stores the key's SHA1Thumbprint for better
identification of keys. Previously on the key name was being
used.
fix annoying NSS Certificate Database password prompt
appearing on Tools->Options if the certificate database is
password protected.
improve Tools->Options->UserData user key selection and
display of information.
add a ui test for "Sign with default certificate"
interaction in the save dialog.
Change-Id: I1036856003f58f494838e0f81ca0fe18e821f528
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171395
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir@allotropia.de>
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>
Xisco Fauli