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>
we can just take a "const &".
(found by running clang-tidy with the
performance-unnecessary-copy-initialization warning)
Change-Id: I20fd208c65303da78170b1ac06c638fdf3aa094b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176267
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
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
This ctor is meant to set the value of nTime directly; and that value
is not nanoseconds, but an encoded value, using SEC_/MIN_/HOUR_MASK.
But in some places, this ctor was misused for setting of nanoseconds,
which would only accidentally work for values less than one second.
All places that initialized tools::Time with 0, now use EMPTY.
This makes the ctor private; and for the very few cases where really
the encoded value of nTime is stored / restored, fromEncodedTime is
introduced.
Change-Id: I1f1994bd9aab1b51a41b1de637619049fe820da4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175283
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Since
commit ad6f23d2a3
Author: TokieSan <eltokhy@aucegypt.edu>
Date: Tue Jul 18 21:54:31 2023 +0300
Added searching and filtering features to certificate chooser dialog
V501 There are identical sub-expressions 'rCharClass.uppercase(sIssuer).indexOf(aSearchStr) < 0' to the left and to the right of the '&&' operator.
Change-Id: Ifdc4b371e6d8f79ad43236e10b86e8e5b03204a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175284
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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
1) Move the try-catch around assing a signature inside the block that
already got the response from the certificate chooser, it's unlikely
that choosing the certificate (and not yet signing) would fail.
2) Convert the dialog to async and allow it to be a jsdialog.
3) Hide not relevant widgets for LOK: we have a single signing
certificate, so the search entry is not useful.
The refresh button has an unclear purpose, as it was initially added
in commit fb9874231f (Caching
Certificates in the CertificateChooser dialog session-wise, 2023-08-26),
but later commit efe414c4a8 (Don't reuse
CertificateChooser instances, 2024-02-07) disabled this chaching. In any
case, the certificate won't change during the lifetime of a single LOK
view, so hide that as well.
4) Invoke the inner certificate viewer in an async way, too.
Change-Id: Ibf618ea7632cf801d1d9180b9aa7dd193c45ffda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174215
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Have two views, in case both of them haver sign certs configured in the
NSS database, then the cert chooser would present both, which is not
wanted.
The problem is that the NSS database contains sign certs from all views,
so working from the database is not what we want for the LOK case.
Fix the problem by passing the SfxViewShell from the sign dialog to the
certificate chooser dialog, and then the chooser can work from the view
in LOK mode.
Searching for other uses of getPersonalCertificates(), the comphelper/
one is not relevant for the LOK case (gpg is disabled there); the PDF
case is only for the UNO API, so those don't necessarily need adjusting.
Change-Id: Ic7027b8d218b2bde3c8bf134a4b11c14fd9c3570
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174002
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Open the sign dialog, the Add button is hidden, even if the LOK clients
initializes the view with a working signing certificate.
SfxMedium::SignContents_Impl() knows the correct view, but by the time
the execution arrives to the DigitalSignaturesDialog ctor, this info is
lost, so we don't know what is the current view.
Fix the problem by looking up the view of the object shell at UNO
command dispatch time, and passing that around, so the signature dialog
can also access it. If the view has a signing certificate configured,
then allow signing.
The certificate chooser triggered by this button still needs fixing.
Change-Id: I1fae63cea27ea1e68e938879f4507f53ade484f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173964
Reviewed-by: Miklos Vajna <vmiklos@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
Open an already signed document, click on the sign icon on the status
bar, notice how the button to remove a signature is hidden.
This was added in commit 71a8bad4b9
(jsdialog: enable Digital Signatures dialog, 2022-01-24), which exposed
the signatures dialog as a read-only jsdialog. The dialog was improved
recently to be a read-write jsdialog, so this is no longer needed.
But then DigitalSignaturesDialog::canRemove() had an inner non-async
message dialog. Fix that by converting canRemove() to async.
An additional problem could be that the document is not marked as
modified, so the LOK client code doesn't notice the document is updated
(to not have a signature), but we do update the last mod timestamp of
the file, which is meant to be enough.
Change-Id: I8e7ee22e4b1b8ce59dee3617bb2f22f8d734f31d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173428
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
This finally allows removing the hack for the LOK case in
SfxObjectShell::CheckIsReadonly() to show the signatures dialog
read-only.
Also fix a case while signing PDFs where the file stream was on the
stack, but now that we finish signing in an async callback, signing
crashed due to a use-after-free.
Fix that by giving the std::unique_ptr to the utl::OStreamWrapper ctor,
which knows to take over ownership in this case, and that wrapper is
reference-counted.
Next problem is that the add/remove buttons in the dialog are still
hidden in the LOK case, that's not yet fixed here.
Change-Id: I71ee50ae55d4e62f5d265a35e3810e3b2b63a9b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173155
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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>
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::signDocumentContent() async, but passing an
std::function via the UNO API is tricky.
Notice how DocumentDigitalSignatures in xmlsecurity/ also implements
sfx2::DigitalSignatures, add a new SignDocumentContentAsync() there and
adapt all uses of signDocumentContent() to go with that instead.
This requires introducing some lambdas for code after
signDocumentContent() in general and for ODF/OOXML specific code in
particular, to avoid code duplication.
Change-Id: If771ced711041364988af45ad9dd0dd1a2a8660d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173060
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
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 NSS password dialog naming the Mozilla profile only shows up for
X.509 certs outside Windows. And the user may wrongly assume GPG keys
are from Thunderbird.
Change-Id: I23706309d57fe30cddcbcac16d7f3e20ee397f16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171645
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
When selecting a X.509 cert on Unix/Linux/macOS. (ODF+PDF signing)
Helps the user to know which password is requested.
Previously only asked for the "NSS Certificate DB" password.
Change-Id: Ic44d3c4b2f98185c07b11f9880d64016aa0b60ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171641
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Before this change, selecting only GPG keys for ODF encrpytion relied on
the fact, that all X.509 implementations (nss+mscrypt) implement listing
public keys (getAllCertificates) as a stub.
See previous change Ia6b8ecb9
Change-Id: Icb36a4cefd60b94407129ff73fe62f9250bfbee5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171639
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
For ODF encryption, only GPG keys are allowed. And key selection for this currently only works correctly, because all X.509 implementations (nss and mscrypt) yield empty results when asked for public keys (encryption).
This commit is a first step to make the selection for GPG keys explicit.
Other code still needs to be changed to make use of this new function
argument.
Change-Id: Ia6b8ecb901c0f54a9a58b1bd0efaa7154ffbd285
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171638
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
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
- "Certificate Path" dialog (select Mozilla profile for NSS)
- resizing broken since commit db9e1ef04d
- also increased default width to account for long filesystem paths
- "Digital Signatures" dialog
- "Select Certificate" dialog
- resizable=True is the default (Glade removes explicit defaults)
- Make long translations wrap instead of being cut.
Glade set expand=False and fill=True as defaults inside GtkBox.
Change-Id: I2d7719e83e5162d06d30e25b3e307fa23e0d605e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170694
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
The commit broke the display of all columns except the first one in all
backends except gtk3.
Also it's not clear why those columns are deemed superfluous;
see discussion in tdf#161871
This reverts commit 9f327102c4.
Change-Id: Idc3496122137f98c23bb7df8e36b17281fc948d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170491
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Usuccessful signing sessions (e.g. abort when password is requested)
left their key in the context.
On the next try, the former key would also be used to sign.
Change-Id: I55b9201df229cae40863a0a19b238029607d1848
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170388
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Tested-by: Jenkins
Miklos Vajna