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>
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
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>
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 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
Seeing as since:
commit e9531b792d
Date: Tue Feb 6 14:39:47 2024 +0100
sal: rtlRandomPool: require OS random device, abort if not present
Both rtl_random_createPool() and rtl_random_getBytes() first try to get
random data from the OS, via /dev/urandom or rand_s() (documented to
call RtlGenRandom(), see [1]).
we don't use the initial arg to rtl_random_getBytes anymore, drop the
requirement to have one. Then simplify our usages of that, and
addtionally deprecate rtl_random_createPool and rtl_random_destroyPool.
Change-Id: I13dcc067714a8a741a4e8f2bfcf2006373f832c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167067
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
gpgme contexts uses the "auto" trust model by default which only
allows encrypting with keys that have their trust level set to
"Ultimate". The gpg command, however, gives the user the option
to encrypt with a certificate that has a lower trust level so
emulate that bahavior by asking the user if they want to trust
the certificate for just this operation only.
Also, abort saving if no certificates are selected which is an
indication that the user cancelled the Select Certificate dialog.
Change-Id: I20951b1e31b2dcf8adb82243742f8c00fbaca8c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165260
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
The cui module has its own UserData struct and when building with
--enable-mergelibs=more, this data collision will cause a crash
when deleting a UserData instance in the xmlsecurity module because
the cui module already has its own, unrelated UserData struct.
Change-Id: I6418b049c72a2e902c9b5076b72fd240f65a593d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164404
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Mike Kaganski