General error when trying to decrypt a public key block in the notepad
Closed, ResolvedPublic
Actions

Assigned To

None

Authored By

	• ebo
	Jul 26 2023, 2:41 PM

Description

Noticed when testing T6188:

If you copy a public key block into the notepad in Kleopatra and click on "sign/encrypt notepad" you get the message "Encryption failed: General error".

Debugview:

[7448] org.kde.pim.kleopatra: GpgME::DecryptionResult(
[7448]  error:                GpgME::Error(117440513 (Allgemeiner Fehler))
[7448]  fileName:             <null>
[7448]  unsupportedAlgorithm: <null>
[7448]  isWrongKeyUsage:      0
[7448]  isDeVs                0
[7448]  legacyCipherNoMDC     0
[7448]  symkeyAlgo:           ?.?
[7448]  recipients:
[7448] )
[7448] GpgME::VerificationResult(
[7448]  error:      GpgME::Error(117440513 (Allgemeiner Fehler))
[7448]  fileName:   
[7448]  signatures:
[7448] )

It would be nice to get a better error.

Details

Version: gpg4win 4.2.0

Revisions and Commits

rM GPGME
	rM777cf7f2d173 core: Return bad data error instead of general error on unexpected data

Related Objects

Mentioned In: T6668: Release GPGME 1.22.0
T6622: Kleopatra: Misleading result when decrypting clear signed message followed by public key block in notepad
Mentioned Here: T6622: Kleopatra: Misleading result when decrypting clear signed message followed by public key block in notepad
T6188: kleopatra: notepad verify/decrypt button not always greyed out when it should be

Event Timeline

• ebo created this task.Jul 26 2023, 2:41 PM

• ebo updated the task description. (Show Details)Jul 26 2023, 2:54 PM

I had a look at this. gpg emits the following status messages:

[GNUPG:] UNEXPECTED 0<LF>
[GNUPG:] FAILURE decrypt 38<LF>

The UNEXPECTED status is handled by _gpgme_verify_status_handler which returns GPG_ERR_GENERAL because sig is null (because no NEWSIG status was emitted). The following change:

--- a/src/verify.c
+++ b/src/verify.c
@@ -978,9 +978,8 @@ _gpgme_verify_status_handler (void *priv, gpgme_status_code_t code, char *args)
 
     case GPGME_STATUS_UNEXPECTED:
       opd->only_newsig_seen = 0;
-      if (!sig)
-       return gpg_error (GPG_ERR_GENERAL);
-      sig->status = gpg_error (GPG_ERR_NO_DATA);
+      if (sig)
+        sig->status = gpg_error (GPG_ERR_NO_DATA);
       break;
 
     case GPGME_STATUS_NOTATION_NAME:

leads to a "No data" error which is more appropriate if no encrypted or signed data is found in the notepad. But I'm not sure whether this change is okay because it changes behavior. Previously, an unexpected packet caused a general error. Now it is simply ignored. This may not be correct behavior when the verification of a signature is expected.

I don't think this can lead to misleading results because gpg exits immediately in --decrypt or --verify mode if an unexpected packet is encountered. For example, putting a PGP PUBLIC KEY BLOCK followed by a PGP SIGNED MESSAGE into Kleopatra's notepad also results in a "No data" error. (For what it's worth: A PGP SIGNED MESSAGE followed by another PGP SIGNED MESSAGE results in a "Bad data" error.) No, wait. A PGP SIGNED MESSAGE followed by a PGP PUBLIC KEY BLOCK leads to a result that suggests that the printed certificates in the public key block where signed. That's bad.

I'll change GPG_ERR_GENERAL to GPG_ERR_UNEXPECTED in the original code. I think that's all we can do. Pity, there's not "Unexpected Data" error.

@ebo @aheinecke @werner What do you think?

No, wait. WHAT? If I put the following into notepad

I get the result

Notepad → Notepad: 
Valid signature by keytocard@example.net

Signature created on Mittwoch, 26. Juli 2023 16:44:51 CEST
With certificate:
Test key for Key to Card <keytocard@example.net> (089F 4ED8 0F38 4779)
The signature is valid and the certificate's validity is ultimately trusted.

and in the text field

bar
pub   ed25519 2022-02-17 [SC] [revoked: 2022-03-28]
      81CE7D2F992F3A1EFEE05931AEEA9B17125B177B
rev        AEEA9B17125B177B 2022-03-28   [selfsig]
uid           Jane Doe <jane.doe@example.net>
sig        AEEA9B17125B177B 2022-08-09   [selfsig]
uid           blabla
sig        AEEA9B17125B177B 2022-08-09   [selfsig]
sub   cv25519 2022-02-17 [E] [revoked: 2022-03-28]
sig        AEEA9B17125B177B 2022-02-17   [keybind]

This happens also with the old code.

The reason seems to be that gpgme_op_verify is used on the input (because the input is classified as a clear-signed message). And this calls gpg without --verify.

Running the same input through gpg --status-fd 2, I get

[GNUPG:] PLAINTEXT 74 0 
bar
[GNUPG:] NEWSIG
[GNUPG:] KEY_CONSIDERED 8C8AFD6AEF9F30C4F6D80CF6089F4ED80F384779 0
[GNUPG:] SIG_ID rNB9tZasKqqfLCkwTNM6ht3SjzU 2023-07-26 1690382691
[GNUPG:] KEY_CONSIDERED 8C8AFD6AEF9F30C4F6D80CF6089F4ED80F384779 0
[GNUPG:] GOODSIG 0F5BE42A23C91CE3 Test key for Key to Card <keytocard@example.net>
[GNUPG:] VALIDSIG D0C16E12A3A5E7857F6FC1D30F5BE42A23C91CE3 2023-07-26 1690382691 0 4 0 1 8 01 8C8AFD6AEF9F30C4F6D80CF6089F4ED80F384779
[GNUPG:] KEY_CONSIDERED 8C8AFD6AEF9F30C4F6D80CF6089F4ED80F384779 0
[GNUPG:] TRUST_ULTIMATE 0 pgp
[GNUPG:] KEYEXPIRED 1647774000
pub   ed25519 2022-02-17 [SC] [revoked: 2022-03-28]
      81CE7D2F992F3A1EFEE05931AEEA9B17125B177B
rev        AEEA9B17125B177B 2022-03-28   [selfsig]
uid           Jane Doe <jane.doe@example.net>
sig        AEEA9B17125B177B 2022-08-09   [selfsig]
uid           blabla
sig        AEEA9B17125B177B 2022-08-09   [selfsig]
sub   cv25519 2022-02-17 [E] [revoked: 2022-03-28]
sig        AEEA9B17125B177B 2022-02-17   [keybind]

which correctly prints the signed plaintext separately from the key block. So, it's probably GpgME that needs to be fixed. Or should gpg have a proper "verify clear-signed (or opaque) signature" mode which rejects unexpected packets just as the "decrypt" mode and the "verify" mode do?

I would change the error to GPG_ERR_BAD_DATA .

What we have here is a clear text signature followed by a public key. If you run this with
gpg -o signedtext.txt --status-fd 2 signedtext.txt should only receive "bar" and not the key listing. If that is not the case something would be very wrong.

ikloecker added a commit: rM777cf7f2d173: core: Return bad data error instead of general error on unexpected data.Jul 28 2023, 2:24 PM

The error was changed to "Bad data" which should be more appropriate.

For the other problem there's T6622: Kleopatra: Misleading result when decrypting clear signed message followed by public key block in notepad.

• werner mentioned this in T6668: Release GPGME 1.22.0.Aug 21 2023, 9:59 AM

Yes the error message is better now. In German it is "Entschlüsseln fehlgeschlagen: Fehlerhafte Daten." Which could be a bit more clear, but its ok

• ebo removed • ebo as the assignee of this task.Sep 12 2023, 3:41 PM

• ebo moved this task from Backlog to WiP on the gpgme board.

• ebo moved this task from WiP to QA for next release on the gpgme board.

• ebo moved this task from QA for next release to gpgme 1.23.x on the gpgme board.

• ebo edited projects, added gpgme (gpgme 1.23.x); removed gpgme.