Description: Hello. My Calc document needs to be digitally signed for a business matter. But when I installed a certificate manager, GPGTools, LO does not recognise it as a certificate manager even though I made sure that it was installed, it still doesn't recognise it. Even though the CA program that I am using, GPGTools, the LO website said that it SHOULD work and detect it inside LO, but it didnt. Can anyone please tell me why? Thank you. Steps to Reproduce: (GPGTools needs to be installed) 1.Open LO and navigate to the Digital Signature window. 2.Click on the "Start certificate manager" button. Actual Results: Once clicked the "Start certificate manager", it said "Could not find any certificate managers". Expected Results: The certificate manager, GPGTools should open up. Reproducible: Always User Profile Reset: No Additional Info: I have verified that I created a digital signature by using the command "gpg --list-signatures"
I installed GPGTools and I see the same bug in LibreOffice 7.6.4.1. Interestingly, in LibreOffice 24.2 (to be released in February 2024), the "Start Certificate Manager" button is disabled. One question: if you press the "Sign Document" button in the same dialog, do you see a list of keys? Or is the list empty? For me, after I launched GPGTools from the Finder, pressed the "New" toolbar button, and created a key, pressing the "Sign Document" document showed the keys that I had just added.
OK. I looked at the source code for that button and it appears to me that macOS was never implemented properly. It looks like this button can only handle Windows and Linux executable paths and it cannot handle launching any macOS applications like /Applications/GPG Keychain.app. Instead, the code tries to launch a ".app" like it is a Terminal command such as "gpg" and that always fails. Note: launching of macOS applications needs to be launched using the /usr/bin/open command. Also on macOS, if no preferred application is found, the LibreOffice help documentation for that dialog states that the Keychain Access application should be launched. But macOS is currently using Linux code: https://cgit.freedesktop.org/libreoffice/core/commit/xmlsecurity/source/dialogs/digitalsignaturesdialog.cxx?id=0c4913e03e8427a576138601958f2dbf13b8c37b
I now see the problem. GetPathAllOS() in xmlsecurity/source/dialogs/digitalsignaturesdialog.cxx is only looking at the PATH environment variable which, on macOS when launched by the Finder, contains only a few constant system paths. I just need to route around this function since ShellExec::execute() appears to handle all of the /usr/bin/open stuff.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/5d2a29ee4f4556b0133e73ea429c9c1aaede0581 tdf#159307 macOS uses Command+Option+F while other plafforms use Ctrl+H
(In reply to Commit Notification from comment #4) > tdf#159307 macOS uses Command+Option+F while other plafforms use Ctrl+H Looks like I had the wrong bug number in the above commit. The above commit is really related to tdf#159326. A fix for this bug is being worked on here: https://gerrit.libreoffice.org/c/core/+/162485
So, while working on a fix, I found another bug that affects all platforms: if you use the Browse button next to the new Certificate Manager button in the Options dialog's LibreOffice > Security > Certificate Manager. It will set that setting to an absolute path. As is, the LibreOffice "Start Certificate Manager" button's code cannot handle that and will, instead, merely grab text after the last directory separator and try to find that in your system PATH. I made a quick attempt at fixing that but my fix has caused a lot of discussion among reviewers. I am just a volunteer so, for now, I'll wait until the Windows and Linux developers fix the absolute path handling. Once they have a fix, I'll retry splicing in the macOS default paths and launching of .app applications: https://gerrit.libreoffice.org/c/core/+/162485
Created attachment 192234 [details] Setting Certificate Manager path via the new Browse button
Created attachment 192235 [details] Screen snapshot of what happens when Start Certificate Manager should behave on macOS
I've attached a couple of screen snapshots that show how the absolute path handling in the following patch currently works on macOS. Maybe it will give the Windows and Linux developers a good example of the cross platform bug that I found: https://gerrit.libreoffice.org/c/core/+/162485 Attachment #192234 [details] shows the new Browse button which displays the native Open dialog. These generally return an absolute path (note: the ".app/" ending on macOS is uniquely a macOS thing). Attachment #192235 [details] shows how the above patch successfully opens the Finder to the application that I set with the Browse button (note: LibreOffice doesn't launch .app applications at this time so, for now, I went with the "show the application in the Finder". Also, if nothing is ever set in the Options dialog (the default state), my fix will launch GPG Viewer.app if it exists or Keychain Access.app if it does not. Unfortunately for macOS users, what problem is that we will need the absolute path handling fix the Windows and Linux engineers.
Setting hardware to all now that we know the lack of absolute path handling will also break the "Start Configuration Manager" button on all platforms. I really wonder if anyone actually tested this button on any platform before shipping it out in LibreOffice 24.2.0. Hopefully, the Windows and Linux developers will resolve this before 24.2.1 is released.
see <https://gerrit.libreoffice.org/c/core/+/162703 tdf#159307> "Fix GetCertificateManager"
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/32ef7cea779ccea9b24ab4776f3069d3a80dd7ed tdf#159307 Fix GetCertificateManager It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The committed patch doesn't fix anything on macOS. I used the Browse button next to the Option dialog's LibreOffice > Security > Certificate Manager field. I select GPG Keychain.app and LibreOffice set the field to /Applications/GPG Keychain.app/ (note the trailing "/" added by the native Open dialog). Select the File > Digital Signatures > Digital Signatures... menu item and, in the dialog that appears, press the Start Certificate Manager button. Not only does nothing happen, but an uncaught exception is thrown which causes the current document to be uncloseable and LibreOffice to be unquittable. I already fixed this in my reject patch: https://gerrit.libreoffice.org/c/core/+/162485
(In reply to Patrick Luby from comment #13) > /Applications/GPG Keychain.app/ (note the trailing "/" added by the native > Open dialog). Note: manually edited the path and removed the trailing "/". No change, still no application launched and can't close a window or quit LibreOffice.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2b1f5fa987f02ec8014dbf6837c6b090faf11f2d tdf#159307 Let non-URIS_ONLY execute() handle .app directories on macOS It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Patrick, please don't take this the wrong way. We are all only trying to be helpful to each other, even if we sometimes fail at that and something might come across more negatively than it was intended. In comment 10, you identified the status quo regarding CertMgrPath set to an absolute system pathname (rather than just a basename, to be searched for in PATH) to be broken on all platforms. My commit from comment 12 tried to address that. I tested that commit also on macOS, where I observed that CertMgrPath set to either an absolute system pathname of an executable (e.g., "/usr/bin/true") or just a basename to be searched forin PATH (e.g., "true") now caused the intended executable to be run. I thus erroneously assumed this issue to be solved for good, and set it to FIXED. I failed to try on macOS with CertMgrPath set to the absolute system pathname of an application's directory (e.g., "/System/Applications/Clock.app"). That should now be addressed with my commit from comment 15. I also ignored the fact that the status quo in CertMgrButtonHdl is problematic with respect to any exceptions thrown from XSystemShellExecute::execute. Something that your proposed Gerrit change from comment 5 would address. I'd welcome it if you re-activated that change and do the relevant fixes. (And I'm un-attaching myself as assignee of this bug again.) What has to be noted, though, is the two modes of XSystemShellExecute::execute as described in the comment at <https://gerrit.libreoffice.org/c/core/+/162485/8#message-2321b00c23d361f3992f5e176a9dffb51698e056> "tdf#159307 XSystemShellExecute::execute() expects file URLs on macOS". What the code in CertMgrButtonHdl wants to do is run an executable, so it should use the non-URIS_ONLY mode with aCommand being a system pathname (as it does). If there are any issues with that mode, esp. on macOS (like the one I tried to address with my commit from comment 15), we should IMO try to address that in the XSystemShellExecute::execute code, not in the code that calls it.
Thank you @Stephan for confirming what I was seeing. With commit https://git.libreoffice.org/core/+/2b1f5fa987f02ec8014dbf6837c6b090faf11f2d%5E%21, "open -a" is working great. I have some time tomorrow so I'll create a new patch and add the list of default macOS paths part of the old patch. I am also need to handle failure of "open -r". Currently that throws an exception in ShellExec::execute(). What do you recommend for handling this? Expand your stat() tests in ShellExec::execute() that return if a path is non-existant or non-executable? Or just add a try/catch block when XSystemShellExecute::execute() is called?
(In reply to Patrick Luby from comment #17) > I am also need to handle failure of "open -r". Currently that throws an > exception in ShellExec::execute(). Sorry, I don't get you here. I don't find an "-r" option for open, do you mean "-R"? And how exactly do you call XSystemShellExececute::execute? (With aCommand being a file URL denoting a directory, and nFlags not containing URIS_ONLY? In which case, where did that passed-in file URL, rather than a system pathname, come from? Did the user manually type it as a URL into the Options dialog, so it ended up that way in the CertMgrPath configuration?)
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/3712014bc7635187ee994126b505e58e2b3c7786 tdf#159307 Fix GetCertificateManager It will be available in 24.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/89046b35d825220014adee558450e0caf5c6027e tdf#159307 Let non-URIS_ONLY execute() handle .app directories on macOS It will be available in 24.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Stephan Bergmann from comment #18) > (In reply to Patrick Luby from comment #17) > > I am also need to handle failure of "open -r". Currently that throws an > > exception in ShellExec::execute(). > > Sorry, I don't get you here. I don't find an "-r" option for open, do you > mean "-R"? And how exactly do you call XSystemShellExececute::execute? > (With aCommand being a file URL denoting a directory, and nFlags not > containing URIS_ONLY? In which case, where did that passed-in file URL, > rather than a system pathname, come from? Did the user manually type it as > a URL into the Options dialog, so it ended up that way in the CertMgrPath > configuration?) Sorry, that was a typo. I meant your new "open -a" code. open -a works for applications but will return an error file regular directories. Also, if the user manually edits the Certificate Manager path and puts in a non-existent and/or non-executable path due to a typo, popen() will return an error. Both types of error cases throw an exception that then makes it impossible to close the document or quit LibreOffice. So, in my original patch, I added something like the following: diff --git a/xmlsecurity/source/dialogs/digitalsignaturesdialog.cxx b/xmlsecurity/source/dialogs/digitalsignaturesdialog.cxx index f2bb37241b7c..97c4c1d39177 100644 --- a/xmlsecurity/source/dialogs/digitalsignaturesdialog.cxx +++ b/xmlsecurity/source/dialogs/digitalsignaturesdialog.cxx @@ -558,8 +558,14 @@ IMPL_LINK_NOARG(DigitalSignaturesDialog, CertMgrButtonHdl, weld::Button&, void) uno::Reference<css::system::XSystemShellExecute> xSystemShell( css::system::SystemShellExecute::create(xContext)); + try + { xSystemShell->execute(sExecutable, OUString(), css::system::SystemShellExecuteFlags::DEFAULTS); + } + catch (...) + { + } } OUString sDialogText = (sExecutable.isEmpty() ?
Yes, the CertMgrButtonHdl code should definitely handle exceptions that SystemShellExecute::execute throws.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/29bf86f7cb367705b13049e5f0b3faa8bb93638a tdf#159307 add default macOS certificate manager applications It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The fix should be in tomorrow's (03 February 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for testers: the nightly master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned like regular LibreOffice releases so you will need to execute the following Terminal command after installation: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
*** Bug 156344 has been marked as a duplicate of this bug. ***
*** Bug 147291 has been marked as a duplicate of this bug. ***
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/ad8033e3beb9eeb44ecfb008f0caa2c5312fc951 tdf#159307 add default macOS certificate manager applications It will be available in 24.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6b6849107562b258aa8858e94ff3c07160f07062 CPU threads: 8; OS: macOS 13.6.4; UI render: Skia/Metal; VCL: osx Locale: en-US (en_DE.UTF-8); UI: en-US Calc: threaded Start Certificate Manager does launch GPG Keychain when installed -> verified. Here are some related follow-up issues: Settings > Security > Certificate Manager > Browse should open applications folder instead of usr/bin https://bugs.documentfoundation.org/show_bug.cgi?id=159586 OpenPGP: don't show confirmation dialog when Certificate Manager was launched successfully https://bugs.documentfoundation.org/show_bug.cgi?id=159587