Description: LO does not allow to encrypt files with public keys with Unkonwn Ownertrust. That is unexpected and should be changed to either allow encryption or warn about the Unknown Ownertrust and allow users to proceed to encrypt the file. Steps to Reproduce: Make sure you have an OpenPGP key in your keychain which has Ownertrust set to "Unknown". On macOS this can easily be achieved by installing GPG Suite (https://gpgtools.com/) opening GPG Keychain double clicking a key and changing the Ownertrust value to Unknown. 1. open writer document and type "test" 2. save as and tick option to "Encrypt with GPG key" 3. select the public key with Unknown Ownertrust Actual Results: LO shows: Warning: OpenPGP key not trusted, damaged, or encryption failure. Please try again. Expected Results: While that info is correct, it should not prevent users from encrypting the document with a public key with Unknown Ownertrust. Using that key from CLI shows a warning but allows usage, which makes sense: gpg: Long key ID: There is no assurance this key belongs to the named user pub rsa2048/long key iD YYYY-MM-DD Name <some@email.org> Primary key fingerprint: 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. GPG Services does not show a warning. It should be one of the two behaviors and I think allowing encryption with keys with Unknown Ownertrust is fine. Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a2265e8faa099d9652efd12392c2877c2df1d1eb CPU threads: 4; OS: macOS 14.4; UI render: Skia/Raster; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
I can reproduce this bug as well. Note: I tried changing the "ownertrust"a third-party public key from "Unknown" to the various options in the GPG Keychain application. The only setting to that worked in LibreOffice was "Ultimate". All others, including "Full", cause this bug to occur.
Had not tested all Ownertrust options, so thanks for going the extra mile. The behavior you discovered makes the problem worse. There really is no reason to attribute Ultimate Ownertrust to public keys, even after verifying them. Ownertrust is relevant to how the web of trust works and ultimate may have unwanted consequences. See also: https://support.gpgtools.com/kb/faq/what-is-ownertrust-trust-levels-explained
(In reply to steve from comment #2) > Had not tested all Ownertrust options, so thanks for going the extra mile. > The behavior you discovered makes the problem worse. There really is no > reason to attribute Ultimate Ownertrust to public keys, even after verifying > them. > > Ownertrust is relevant to how the web of trust works and ultimate may have > unwanted consequences. > > See also: > https://support.gpgtools.com/kb/faq/what-is-ownertrust-trust-levels-explained Thank you for the link. I admit that I've never really undertstood the intricacies of digital signing and key encryption. I'm just here because you have posted some of the most unusual crash logs that I have ever seen in my 20+ year's of macOS debugging. This stuff is all new to me as developer. I'm mostly used to trying to wire-up the Windowsy LibreOffice code to work with macOS. Anyway, what is the lowest level that should be trusted? Full? Untrusted? I assume that these levels correspond to some value in code.
I ran LibreOffice in a debugger and found the code that fails. In the following code in comphelper/source/misc/storagehelper.cxx, gpgme's ctx->encrypt() function returns an error (error code 53) and len is 0. I verified that "keys" contains a single cert with the same fingerprint as shown in the GPG Keychain application. So, the question is why is this gpgme function failing when a public key's Ownertrust is not set to Ultimate?: GpgME::EncryptionResult crypt_res = ctx->encrypt( keys, plain, cipher, GpgME::Context::NoCompress); off_t result = cipher.seek(0,SEEK_SET); (void) result; assert(result == 0); int len=0, curr=0; char buf; while( (curr=cipher.read(&buf, 1)) ) len += curr; if(crypt_res.error() || !len) throw lang::IllegalArgumentException( "Not a suitable key, or failed to encrypt.", css::uno::Reference<css::uno::XInterface>(), -1);
One thing I noticed is that both GPGTools' public keys in GPG Keychain show "validity" as "unknown". The only way I can change the validity is by changing the Ownertrust to Unlimited.
Interestingly, I found that the gpg command (which is what the gpgme code uses to access keys and encrypt data) also expects a public key to have Ownertrust set to Ultimate. The following is what gpg outputs when the support@gpgtools.org key in the GPG Keychain application is has Ownertrust set to "Full" or lower. What I think we need is to find out if gpgme has some way to force the "Use this key anyway?" set to "yes" behavior: % gpg -r support@gpgtools.org --output blah.encrypted --encrypt blah.txt gpg: B35D2E404496652B: There is no assurance this key belongs to the named user sub rsa4096/B35D2E404496652B 2020-05-04 GPGTools Support <support@gpgtools.org> Primary key fingerprint: B97E 9964 ACAD 1907 970D 37CC 8A9E 3745 558E 41AF Subkey fingerprint: 1ACA 7D43 C040 6099 0604 C033 B35D 2E40 4496 652B It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) y
I found something in gpgme that will stop the failure to encrypt with public keys with any Ownertrust value: set gpgme's "trust model" to "tofu" or "always". Both of these seem to ignore key validation completely so I doubt that this is a good solution, but maybe some developers more familiar with gpgme than me might know of an alternative gpgme option. Debug patch that I used to set the trust model is below: diff --git a/comphelper/source/misc/storagehelper.cxx b/comphelper/source/misc/storagehelper.cxx index 1d504cb91725..cca834dc94c6 100644 --- a/comphelper/source/misc/storagehelper.cxx +++ b/comphelper/source/misc/storagehelper.cxx @@ -480,6 +480,7 @@ uno::Sequence< beans::NamedValue > OStorageHelper::CreateGpgPackageEncryptionDat if (ctx == nullptr) throw uno::RuntimeException("The GpgME library failed to initialize for the OpenPGP protocol."); ctx->setArmor(false); + ctx->setFlag("trust-model", "tofu"); for (const auto & cert : xSignCertificates) {
After reading the gpg man page for --trust-model, I tried using "tofu+pgp" which appears to do some validation of trust in the following debug patch. The man page mentions setting --tofu-default-policy=unknown so I set that as well and encryption still works. @Thorsten is tofu+gpg too loose of a trust model?: diff --git a/comphelper/source/misc/storagehelper.cxx b/comphelper/source/misc/storagehelper.cxx index 1d504cb91725..8ba27b41408f 100644 --- a/comphelper/source/misc/storagehelper.cxx +++ b/comphelper/source/misc/storagehelper.cxx @@ -480,6 +480,8 @@ uno::Sequence< beans::NamedValue > OStorageHelper::CreateGpgPackageEncryptionDat if (ctx == nullptr) throw uno::RuntimeException("The GpgME library failed to initialize for the OpenPGP protocol."); ctx->setArmor(false); + ctx->setFlag("trust-model", "tofu+pgp"); + ctx->setFlag("tofu-default-policy", "unknown"); for (const auto & cert : xSignCertificates) {
Untrusted is expected for any key you import. The two public keys that come pre-installed have unknown Ownertrust for that very reason. The idea is for users to check validity of their keys and then set a trustlevel matching that. GPG Services, the gnupg tool integrating into macOS Services menu does not require the confirmation and allows to encrypt to any valid (but not necessarily trusted) public key. Command line gpg does ask the user how to proceed when the key is untrusted. I am fine either way for LO, leaning towards allowing encryption without a warning. Current behavior certainly is not intended.
(In reply to steve from comment #9) > Command line gpg does ask the user how to proceed when the key is untrusted. > > I am fine either way for LO, leaning towards allowing encryption without a > warning. Current behavior certainly is not intended. Maybe I can mimic the gpg command line behavior by using the existing code (i.e. with the strictest trust model) and then, if it fails with this specific error, I modify the code to display a "Yes/No" dialog that asks "The public key is untrusted. Do you still want to encrypt with this key?". If yes, then the code retries encrypting with either "tofu+pgp" or "always" as the trust model. I am a bit busy this week, but if that seems like a reasonable approach, I'll see if I can implement it when I have some spare time.
Created attachment 193276 [details] Snapshot of new dialog for each selected but untrusted public key
(In reply to Patrick Luby (volunteer) from comment #11) > Created attachment 193276 [details] > Snapshot of new dialog for each selected but untrusted public key I have the "ask and retry" code in the following patch: https://gerrit.libreoffice.org/c/core/+/165260 Are any changes needed to the text in the dialog in attachment #193276 [details]? Note that with this patch, if you select more than one key to encrypt with, you will see the new dialog once for each untrusted public key until the first No is pressed. Also, I noticed that if the Select Certificate dialog is cancelled, LibreOffice would save the file unencrypted. That seems like an accident waiting to happen to me so with the patch, cancelling the Select Certificate dialog also cancels saving.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6a049e417b029f3733fcee05f99a3e8875aefdb8 tdf#160184 ask user if they want to trust an untrusted certificate 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 for this bug has been. The fix should be in tomorrow's (27 March 2024) nightly master builds. The dialog wording will likely change in a separate commit as the current text doesn't really convey the same level of risk that the gpg command does: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS 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 but before you launch /Applications/LibreOfficeDev: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Created attachment 193351 [details] Snapshot of modified dialog text that emphasizes risk of using an untrusted public key
(In reply to Patrick Luby (volunteer) from comment #15) > Created attachment 193351 [details] > Snapshot of modified dialog text that emphasizes risk of using an untrusted > public key I have submitted the following patch with my current proposed changes to the dialog wording: https://gerrit.libreoffice.org/c/core/+/165396 Attachment #193351 [details] shows what the text looks like in my local build.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c4023d3ec604abfff38be2053e2989c7ec2ba8c1 Related: tdf#160184 clearly describe security risk 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.
Minor nitpick: The warning about encrypting with an untrusted key is titled "Error". That seems wrong. Can that be re-labeled to "Warning" as that what the following text is. Error is actually misleading since it suggests to the user that there is a technical problem which there isn't. Not sure about the man in the middle reference. Think what I am getting at is that an untrusted key is no indicator of a man in the middle attack as a verified key is not a guarantee a man in the middle attack is not happening or preventing it in any way if it is happening. Since this went by the eyes of both Thorsten and Heiko it is probably a keeper. Setting to verified as implementation does what is expected. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2c724d88fef38a390744bbe1a4add031c6c62843 CPU threads: 4; OS: macOS 14.4.1; UI render: Skia/Raster; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Follow-up bug: https://bugs.documentfoundation.org/show_bug.cgi?id=160701