Add UnoApiTest::disposeAndLoadFromURL for tests where
we need to close the current document and open a new one
Change-Id: Ia9419d0743f4a1c22d8c4d8b91bc168cd43533d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198966
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
On a Mac volume mounted in a Linux virtual machine under Parallels
Desktop, hard-linking works (from the Linux VM). Looking at it in the
host macOS the linked files also show up as linked, with identical
inode number and a link count of 2. But in the Linux VM, the
hard-linked files each have a link count of 1, and different inode
numbers. (Still, they *are* the same file. If you write to one, it
shows up in the other, too, etc.)
I am not saying it necessarily makes sense to build core on such a
file system. Quite likely it makes more sense to just create a native
Linux file system on a Parallels virtual hard drive (that is a file on
a Mac volume). But it is fun to experiment with stuff like this.
Yes, if it turns out that we need to get the name of the file system
type some folder or file is on in other places, too, the code for that
should be put in some shared place.
Change-Id: I315eb2ed0fd0803da3070645119b2bd3019cc9a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197305
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
now that Bitmap supports transparency
Disable part of the redaction test. I have
verified that the visual result of auto-image redaction
is the same before and after this change, but we
seem to end up with more rectangles than before.
Probably something weird inside the EMF/WMF machinery.
(see the fixMetaFile function).
Change-Id: I85f308ae66ddf7592e41fde1ab9e49f9c882146e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190338
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This changes the LOK API added in commit
e9e39e45f0daed52276377321088aa4d49b112b6 (cool#11064 vcl lok: expose
info about the scheduler, 2025-02-14) so that a LOK client doesn't have
to query the priority of the most urgent task: instead the anyInput
callback gets it as a parameter.
The scheduler is a hot path and it's not expected this priority
information would be needed in other places, so folding the new LOK API
into the anyInput callback simplifies things.
Change-Id: I1385055bfa27f47a243d40683b54cb2ddc9d33bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181878
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
A LOK client can interrupt the vcl main loop in its 'any input'
callback. When making that decision, it's useful in case it can know
what's the priority of the most urgent job, for example it may want core
to still finish high priority tasks, but not idle ones.
Add a LOK API to expose this info. Keep it minimal, so it's realistic to
call this frequently from a LOK client.
Change-Id: Id51668eb8156067e60d6fd0f33606c65858008a9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181761
Reviewed-by: Miklos Vajna <vmiklos@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
Insert a signature line in "extern" mode, the shape gets selected but
there is no graphic selection at a LOK API level.
This is because GetSignPDFCertificate() returned an XCertificate, which
is empty in the external signing case, so we can't differentiate between
no signing and external signing.
Fix this by changing the return type to svl::crypto::CertificateOrName,
this way SdrMarkView::SetMarkHandlesForLOKit() can annotate the
signature line correctly even in the external signing case.
The tracking of the signature line selection is still in the model (not
in the view), that's not yet fixed here.
Change-Id: I4ef9c1fa0a88af0c0fcd55156b973a3705f985c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180296
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
It turns out the majority of getCommandValues() return values specify a
commandName and a commandValues key, which is helpful when we don't
track the request for this reply.
Fix .uno:Signature to do the same for consistency.
Change-Id: I46ffe5c36047ef2b59113d0221a1874ba28d335b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177857
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Whatever the reason, but running the test against a read-only SRCDIR caused
CppunitTest_sfx2_view
CPPUNIT_TEST_NAME=testLokHelperCommandValuesSignature::TestBody to fail with
> sfx2/qa/cppunit/view.cxx:138:testLokHelperCommandValuesSignature::TestBody
> assertion failed
> - Expression: nSignatureTime != 0
Change-Id: I35d7df0de1b63937920687444ea0698fc0856446
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177302
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
Now that the hash extract part works, the other end of this external
signature support is to be able to integrate an externally generated
(e.g. qualified) signature into our PDF file.
The problem is that we have SignDocumentContentUsingCertificate() for
non-interactive signing and we have the interactive sign dialog, but we
have no way to integrate an existing PKCS#7 blob.
Fix the problem by extending vcl::filter::PDFDocument::Sign(): if a
signature value is provided, then integrate that, instead of calling
svl::crypto::Signing::Sign() to generate a new signature.
Also extend the SigningContext documentation, since now it has 3 modes
(normal sign, hash extract, sign serialize).
Change-Id: I113fb536b1a83b8a4869a7064bb415bca6a91ae4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176623
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Execute getCommandValues('Signature') on the same document twice, you
get different hashes, because the content includes a timestamp, which
changes, so it's not possible to know if the hash is stable or not.
Also, working with a provided timestamp will needed for
<https://docs.eideasy.com/electronic-signatures/api-flow-with-file-hashes-pdf.html#_4-add-the-signature-to-the-pdf-file>
anyway.
Fix the problem by adding a signatureTime parameter and this way we can
have a test that makes sure we get the same hash if the time is
provided.
With this, the hash extraction part is meant to be ~complete.
Change-Id: If5e1e5bcf84c3b777f26b2ded24dcca48ea9ad94
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176601
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
To be able to sign externally, we need a way to know what is the
document hash that would be passed to
NSS_CMSSignedData_SetDigestValue(), without actually performing the
signing.
Note that svl::crypto::SigningContext already gives us a way to expose
the time that would be used for signing.
Expose the hash in a similar way: the format is a SHA-256 hash in base64
form.
This adapts both places dealing with time: vcl::PDFWriter::GetDateTime()
and svl::crypto::Signing::Sign, to make sure they use the same time,
otherwise the hash would potentially depend on two times, which would be
hard to reproduce later when we serialize the signature we get.
Change-Id: Ib039db4cdd043c8117215c31cb5bc83397693820
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176470
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
1. Make it take string view: helps to avoid extra string allocation
e.g. in desktop::jsonToPropertyValuesVector, and will help more,
when C++26 stringstream ctor taking string view is available.
2. Factor out a function taking boost::property_tree::ptree, making
implementation simpler for [][]com.sun.star.beans.PropertyValue and
[]com.sun.star.beans.PropertyValue, without writing a child node to
a JSON string, and parsing it again.
Change-Id: I16ac2641633ea67a7c9c054c9df09a790500e6fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175361
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@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
Load a document, sign it, "green" icon on the status bar. Reload the
document, turns into a "yellow" icon saying the CA is not trusted, when
it was already trusted before.
The trouble is that the document signature status is calculated on load,
and the CA to be trusted is only given later, as part of the
initialization of the LOK view.
Fix the problem by invalidating the signature state when a new CA is
trusted.
The test document was produced by signing an empty document using the
keys from xmlsecurity/qa/xmlsec/data/, which gives us a way to create a
signature that is initially not trusted.
Change-Id: I1e1dbf616ce54c4823d62104f838342de6870f52
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174307
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
The desktop way to sign documents is to manually import a .p12 file into
your Firefox user profile, and then the signing key is available in all
views. The LOK case wants per-view signing certificates, set in a way
similar to the name of the user.
Start implementing this by:
1) Extending initializeForRendering() to have JSON entries for the
signing cert/key/ca chain.
2) Importing the CA chain as trusted certificates, using a new
SfxLokHelper::extractCertificates() + test for this.
3) Marking a certificate as trusted is tricky, extract
SfxLokHelper::addCertificate() from the existing doc_addCertificate()
to do this.
4) Parsing the signing certificate, but just warn if that fails, still
need to connect that to the SfxViewShell later.
Change-Id: I00e40b3cdd68dbe8994f28861dc7b0f578189643
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173806
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
so they can make use of CPPUNIT_ASSERT_STATEMENT_EQUAL
They were moved ported from Java to CppUnittest in
commit e42be49887
Author: Xisco Fauli <xiscofauli@libreoffice.org>
Date: Wed Jul 3 10:09:54 2024 +0200
tdf#123293: port test from Java to CppUnitTest
and
commit d6ad09ca88
Author: Xisco Fauli <xiscofauli@libreoffice.org>
Date: Tue Jul 2 18:00:26 2024 +0200
sfx2: port checkRDFa from Java to CppUnittest
Change-Id: I7b91bde6d968081a5b1c0bbee42208590e062ea8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173622
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Create a read-only file, try to save-as the current document and select
the existing read-only file, accept to overwrite it, works fine.
This is a regression from commit
2157a3536f (sfx2 store: try rename before
copying, 2018-01-09), previously such read-only targets were rejected.
Fix the problem by explicitly checking if the target is writable: if
not, then avoid the rename optimization, because the fallback path will
reject the request as expected.
Fix this inside an '#ifdef UNX' block, the problem is reportedly not
there on Windows.
Change-Id: Ifd8798e07a1be504c6747514a53cfc4ff2338a0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173344
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
TESTRDFA.odt is still used by checkTdf123293.
(To be ported in a follow-up commit)
while at it, move existing 'hello.odt' file from
misc to data, this is the normal folder name
for files everywhere
Change-Id: I3ab12550e1d2e7654cb59c55c6da40b6c28b7e46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169888
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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>
Scripting clients (like the LOK API) had a way to get all custom
properties where the name matches a certain prefix, but setting such
properties was not possible.
.uno:SetDocumentProperties can already show a dialog to edit properties
interactively and had a parameter to set some properties in a
non-interactive way, but there doesn't seem to be a way to influence
custom properties there without using the internal API.
Fix the problem by adding a new UpdatedProperties parameter that allows
removing all old custom properties matching the prefix and adding new
ones with a single UNO command dispatch.
This is meant to be the write side of the reading commit
5e8f6dcb8c (sw lok,
.uno:SetDocumentProperties: expose value of custom document properties,
2022-11-29).
Change-Id: Ib7450d4d21285d9a73758e1c172543521fc07cef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143491
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Gabor Kelemen