summaryrefslogtreecommitdiff
path: root/xmlsecurity/source
AgeCommit message (Collapse)AuthorFilesLines
2025-03-30Use osl_getEnvironment instead of getenvMike Kaganski1-5/+7
Avoids conversion to OUString; and is Unicode-safe on Windows. Change-Id: Idd82f589ae9bf692ce2e73f84cb664a68156915a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183507 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2025-03-26Move Windows error helpers to comphelper namespacevarshneydevansh3-6/+6
Previously, WindowsErrorString and WindowsErrorStringFromHRESULT were defined in an anonymous namespace in windowserrorstring.hxx, which: 1. Made them unavailable to other translation units 2. Violate ODR by creating separate copies in each TU 3. Require workarounds to access them Changes: - Move functions to proper comphelper namespace - Keep implementations inline as they're simple utilities - Preserve all existing functionality - Update all call sites to use comphelper:: prefix This change enables proper use of these utilities across LibreOffice while maintaining current behavior and performance characteristics. Introduced in this commit: commit 94cdcaa4d8db8f03ac9a84dac54357efff3eb123 Author: Tor Lillqvist <tml@collabora.com> Date: Thu Aug 13 13:22:28 2015 +0300 Add a globally usable WindowsErrorString function Change-Id: I34df1c2b1f30c6204f107ca4792131d692203880 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183332 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2025-03-10use more concrete UNO classesNoel Grandin2-25/+15
Change-Id: Id10786bbf7985adbb251224b45f9dabcc84d0a3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182721 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2025-01-29tdf#161872 xmlsecurity mscrypt: don't require trusted signing certsMiklos Vajna1-0/+1
See commit 1817760f56b74e47120c1b4d7641fbaebcf378ad (tdf#161872 xmlsecurity nss: don't require trusted signing certs, 2025-01-28), this is the same situation, but this time on Windows. Change-Id: I945899da47ab5dcc421f35db31ec7af240c59b8c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180881 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2025-01-28tdf#161872 xmlsecurity nss: don't require trusted signing certsMiklos Vajna1-0/+1
Configure your signing cert in Firefox, (unusually) don't trust the CA that you would use to issue your signing cert, try to sign a document, error. This is reportedly wrong since commit bfd479abf0d1d8ce36c3b0dcc6c824216f88a95b (Update libxmlsec to 1.3.1, 2023-06-09), for some reason our usage of libxmlsec-1.2 didn't trigger this problem. Given that we already disable libxmlsec-side cert verify while verifying a signature (and have our own logic there), it's consistent to do the same while creating the signature, and that fixes the bug, too. The Windows / MSCNG backend is not yet changed here. Change-Id: I8a7adf06b9a26731f1a180a4f6257317084e414a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180844 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2025-01-16cool#10630 doc electronic sign: move signature line tracking to the viewMiklos Vajna1-11/+5
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
2025-01-13cool#10630 doc electronic sign: fix insertion of the signature lineMiklos Vajna2-3/+4
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>
2025-01-06cool#10630 lok doc sign: fix Impress sign line when picking a certificateMiklos Vajna1-8/+21
Once .uno:InsertSignatureLine gets dispatched, a visual signature placeholder gets inserted, then a certificate picker shows up, but no certificates are visible in the list. The first problem is that .uno:InsertSignatureLine needs to take sign key/cert parameters in DrawViewShell::FuPermanent() (similar to .uno:Signature), so it can learn what certificate to use for signing. The second problem is that once that sign cert is attached to the view, the cert chooser for signature lines were not taking the sign cert from the view in DocumentDigitalSignatures::chooseCertificatesImpl() -- this needs routing the info about the current view from sd/ (where we still have that info) to xmlsecurity/. With this, a LOK client dispatching .uno:InsertSignatureLine with the 2 new parameters set can insert a signature line, it'll show up, but the subsequent .uno:Signature dispatch still needs fixing up. (Currently it wants to "save" the modified PDF, while it should just sign.) Change-Id: Ie536842152ef097aa6959c67916f2beb6d356e4a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/179819 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-12-22tdf#152299 - Remove unused define(s) from C/C++ filesBogdan Buzea1-1/+0
Change-Id: I051f33ac28bdc1e3922d2d390ff3234204b80688 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177186 Reviewed-by: David Gilbert <freedesktop@treblig.org> Tested-by: Jenkins
2024-12-07weld: Rename weld::Treeview selection signal/connectMichael Weghorn4-6/+10
Rename weld::TreeView member + methods to clarify that these are about selection changes: * m_aChangeHdl to m_aSelectionChangedHdl, * signal_changed to signal_selection_changed * connect_changed to connect_selection_changed In GtkInstanceTreeview, also rename the related methods calling signal_selection_changed accordingly for consistency. Change-Id: I299d7930484677395a0bdd0ff105df18688f2e04 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178023 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-12-03don't bother passing const std::[u16]string_view by referenceCaolán McNamara1-4/+3
Change-Id: I49477c20849dd99118d5935c0f1576429648bfca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177734 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-11-26Operator should be logical AND instead of ORAron Budea1-1/+1
Change-Id: Ife1870da9979e974fa9dc11ca7dff87c8cfe66bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177310 Tested-by: Jenkins Reviewed-by: Aron Budea <aron.budea@collabora.com>
2024-11-11cool#9992 lok doc sign, hash extract: time for getCommandValues('Signature')Miklos Vajna4-21/+35
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
2024-11-10com::sun::star -> cssMike Kaganski1-3/+3
Change-Id: I890ec73e30d3cc6b210903ecee29431f3cb5f635 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175979 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-11-08cool#9992 lok doc sign, hash extract: initial getCommandValues('Signature')Miklos Vajna1-10/+15
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>
2024-11-08no need to take a copy of the getProcessComponentContext return valueNoel Grandin4-4/+4
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
2024-11-07loplugin:passstuffbyref in ucb..xmlsecurityNoel Grandin1-1/+1
Change-Id: I734a4ca69e1b2770613beb3a05d770b7fc7343b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176203 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-11-04new loplugin:staticconstexprNoel Grandin2-2/+2
Change-Id: Ida1996dfffa106bf95fd064e8191b8033b4002f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175336 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-10-21Make tools::Time ctor taking sal_Int64 privateMike Kaganski1-4/+4
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>
2024-10-20tdf#163486: PVS: identical sub-expressionsXisco Fauli1-1/+0
Since commit ad6f23d2a3842c40f7c812003af4031150ea8183 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>
2024-10-02Add ODF 1.3 Extended / ODF 1.4 versions to configuration and UIXisco Fauli1-1/+1
The new default is ODF 1.4 Extended Change-Id: I50f60cccde81b5ea320478314482cc67a7bcc2e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174343 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-09-30cool#9992 lok doc sign: convert the certificate chooser dialog to asyncMiklos Vajna3-31/+60
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 fb9874231fb242b4a6a7d1ce097e66dd4ed8f32e (Caching Certificates in the CertificateChooser dialog session-wise, 2023-08-26), but later commit efe414c4a88fde0e2ee1d4016010f21fbd6d01d7 (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
2024-09-27cool#9992 lok doc sign: only take sign cert from the view in the cert chooserMiklos Vajna3-3/+22
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
2024-09-26cool#9992 lok doc sign: conditionally show the add button in the sign dialogMiklos Vajna2-7/+16
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
2024-09-25cool#9992 lok doc sign: fix import of the private keyMiklos Vajna1-1/+3
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 87eec1b90b6ecd83455f09168430c23f73c25c86 (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
2024-09-16cool#9992 lok doc sign: implement signature removalMiklos Vajna1-25/+32
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 71a8bad4b96627fd965b23288dea14aae3f0f468 (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
2024-09-13[API CHANGE] XDocumentDigitalSignatures: remove deprecated / unused functionsMiklos Vajna3-87/+0
Some functions were already a stub and only aborted on calling them. The *Package* functions were added in commit c9ed2f359a9e899c3046c8151c831e24250fddbb (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>
2024-09-12cool#9992 lok doc sign: allow sign of macros & the document itself in one stepMiklos Vajna5-8/+86
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
2024-09-11cool#9992 lok doc sign: async read-write DigitalSignaturesDialogMiklos Vajna1-18/+15
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>
2024-09-10cool#9992 lok doc sign: async DocumentDigitalSignatures::ImplViewSignatures()Miklos Vajna2-20/+60
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 067a8a954c8e1d8d6465a4ab5fb61e93f16c26c2 (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>
2024-09-09cool#9992 lok doc sign: async DocumentDigitalSignatures::signDocumentContent()Miklos Vajna1-4/+16
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>
2024-08-31cid#1607713 silence Overflowed constantCaolán McNamara1-3/+3
Change-Id: I0b3b924689685cfb7ae5cd64db5e3ef371541769 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172700 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-08-13tdf#161909: show where the certs in the CertificateChooser are fromMoritz Duge1-0/+36
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>
2024-08-13tdf#161909: show NSS cert DB path (MOZ profile) in password dialogMoritz Duge1-1/+6
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>
2024-08-13tdf#161909: make showing GPG keys only an explicit functionalityMoritz Duge1-3/+4
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>
2024-08-13tdf#161909: request GPG keys exclusively for chooseCertificatesImplMoritz Duge2-2/+4
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>
2024-08-08tdf#161909: Show key type in CertificateViewer.Moritz Duge1-0/+2
Change-Id: I4277e342c573525dd668d0365b1d686fe33fd914 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171500 Reviewed-by: Moritz Duge <moritz.duge@allotropia.de> Reviewed-by: Sarper Akdemir <sarper.akdemir@allotropia.de> Tested-by: Jenkins
2024-08-05tdf#159040 tdf#162206: better the user key selection and test sign with defaultSarper Akdemir2-5/+6
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>
2024-08-04cid#1556583 COPY_INSTEAD_OF_MOVECaolán McNamara1-1/+1
and cid#1556585 COPY_INSTEAD_OF_MOVE cid#1556588 COPY_INSTEAD_OF_MOVE cid#1556593 COPY_INSTEAD_OF_MOVE cid#1556597 COPY_INSTEAD_OF_MOVE cid#1556605 COPY_INSTEAD_OF_MOVE cid#1556617 COPY_INSTEAD_OF_MOVE cid#1556635 COPY_INSTEAD_OF_MOVE cid#1556790 COPY_INSTEAD_OF_MOVE cid#1556792 COPY_INSTEAD_OF_MOVE cid#1556796 COPY_INSTEAD_OF_MOVE cid#1556799 COPY_INSTEAD_OF_MOVE cid#1556815 COPY_INSTEAD_OF_MOVE cid#1556836 COPY_INSTEAD_OF_MOVE cid#1556840 COPY_INSTEAD_OF_MOVE cid#1556842 COPY_INSTEAD_OF_MOVE cid#1556859 COPY_INSTEAD_OF_MOVE cid#1556860 COPY_INSTEAD_OF_MOVE cid#1556866 COPY_INSTEAD_OF_MOVE cid#1556869 COPY_INSTEAD_OF_MOVE cid#1556870 COPY_INSTEAD_OF_MOVE Change-Id: I3df8698a4aecbb03999c084517e37e12ff46ee97 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171435 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-07-25tdf#161909: Fix resizing and behavior for "View Certificate" dialog.Moritz Duge1-3/+9
- Set appropriate larger default size. - Disable editing of details area. - Add comments to distinguish GPG and X.509 code. Change-Id: Idcca012c1eef96c6daa78498e85da6f70c97a90f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170004 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-07-15tdf#161871 Revert "Removed Type and Usage Columns from Certificate Chooser"Samuel Mehrbrodt1-4/+13
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 9f327102c435887bbae650b3a573f44500b6f534. Change-Id: Idc3496122137f98c23bb7df8e36b17281fc948d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170491 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2024-07-15tdf#108828 Prevent leaking keys from previous signing sessionsSamuel Mehrbrodt1-0/+2
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
2024-07-14cid#1608236 COPY_INSTEAD_OF_MOVECaolán McNamara1-1/+1
Change-Id: I3f46c1d7e68dbf79ddbc9dc50d2735ebe1727b14 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170445 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-07-11tdf#108828 Show certificate selector again after cancelling password dialogSamuel Mehrbrodt1-1/+2
Change-Id: I0a57204c1885ca300d22832e5469d8918aec9ba6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170384 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
2024-05-23tdf#145538 Use range based for loopsU-AMANDAQUARESMA\quare1-3/+3
Change-Id: Ib672cd1968de7bb99cd5f8737a09ce02b0490bf8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167995 Tested-by: Jenkins Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2024-05-15loplugin:ostr in xmlsecurityNoel Grandin36-538/+551
Change-Id: Ifb936c230f68447b3bb5993705adb5e5b790371f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167668 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-05-12WaE: C6011 Dereferencing NULL pointer warningsCaolán McNamara1-0/+1
Change-Id: I19824cd8fdc3ac5b5afb4e769527bf71513212fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167553 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-05-09WaE: C6011 Dereferencing NULL pointer warningsCaolán McNamara1-0/+1
Change-Id: I6ef2f39cca9e657a05b9b55d8ff87607261dd1ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167369 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins
2024-05-08drop requirement for rtl_random_getBytes to have "Pool" argCaolán McNamara1-3/+1
Seeing as since: commit e9531b792ddf0cfc2db11713b574c5fc7ae09e2c 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>
2024-05-04WaE: C6011 Dereferencing NULL pointer warningsCaolán McNamara1-1/+1
Change-Id: I68acd56b28b0f989a4010cd939f2452970d158ff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167103 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-05-18 18:22:09 +0000