Open Bug 1884508 Opened 6 months ago Updated 4 months ago

gpg mime mode (6d) not compatible with thunderbird (encrypted mode m)

Categories

(MailNews Core :: Security: OpenPGP, defect)

Thunderbird 115
defect

Tracking

(thunderbird_esr115 affected)

Tracking Status
thunderbird_esr115 --- affected

People

(Reporter: aeris, Unassigned)

References

Details

(Whiteboard: [RNP])

Attachments

(2 files)

Steps to reproduce:

Recently I upgrade from kgpg 23.08.5-1 to 24.02.0-1
Now all my GPG encrypted message is no more decrypted by Thunderbird (blank message).
No information about the trouble is available, debug information on Thunderbird seem meaningless.

Debugging in CLI give a single difference: encrypted mode is now m (mime, 6D) and no more b (binary, 62)

Working encrypted email:

:literal data packet:
mode b (62), created 1709827228, name="",
raw data: unknown length

Not working encrypted email:

:literal data packet:
mode m (6D), created 1709981834, name="",
raw data: unknown length

Actual results:

Blank message when displaying a KGPG 24.02 encrypted message (works with KGPG 23.08)

Expected results:

Thunderbird must decrypt and display the decrypted message

Attached file Bugged email

Duplicate of #1884506.

Component: Message Reader UI → Security: OpenPGP
Product: Thunderbird → MailNews Core
Duplicate of this bug: 1884506

Which software was used to produce the message that you cannot decrypt with Thunderbird?

RFC 4880 doesn't define that mode. (section 5.9, literal data packet, tag 11).

Flags: needinfo?(aeris)

Well, you said it was KPGP, which is an interface to GnuPG. My question is, do you know what underlying version of GnuPG you were using?

gpg (GnuPG) 2.4.4
mime format is defined in rfc4880bis
https://wiki.gnupg.org/rfc4880bis#Literal_data_packet

Thunderbird doesn't support rfc4880bis.

That's a GnuPG-specific modification of the OpenPGP specification.

GnuPG is the de facto standard. Having Thunderbird not supporting the main GPG software with features implemented since 2016 mainstream in GnuPG is definitively a problem.

Flags: needinfo?(aeris)

The problem is that the OpenPGP specification has been forked.

Thunderbird hasn't yet decided which of the forks it should support.

Seems not a recent fork. 4880bis is implemented on GnuPG at least for mime data format since 2016 🤔
https://lists.gnupg.org/pipermail/gnupg-commits/2016-July/012351.html

For what I understand RNP just stuck on 2007 RFC version when deciding to implement GPG natively in Thunderbird in 2017, with 4880bis existing since at least 2 years (2015) and with IETF working group active on it, and 3 years after the 2014-2016 crypto-apocalypse (heartbleed, Snowden, ECC, AEAD, SHA-1…)?

rfc4880bis as available in the past was a draft document, not a standard.

The standardization of OpenPGP is currently in an unfortunate situation. In 2020 the OpenPGP working group at the IETF was rechartered to perform work to evolve 4880bis into a new version of the OpenPGP standard (see https://datatracker.ietf.org/doc/charter-ietf-openpgp/02/).

Initially all relevant actors, including GnuPG, participated in this process. However, around 1.5 years ago, GnuPG effectively opted to stop working with the group that is developing this revision draft, draft-ietf-openpgp-crypto-refresh.

In draft-ietf-openpgp-crypto-refresh, produced within the IETF process (and expected to be finalized within the coming weeks), valid values for the literal packet data type are more limited: https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-13.html#name-literal-data-packet-type-id

(As an aside, note that while GnuPG is certainly a big actor in OpenPGP, it is by far not the only implementation with a serious footprint. Multiple other implementations are used by hundreds of k, or millions of users.)

@aeris, RNP is not stuck on RFC 4880, we just somehow missed this mime flag and will implement it in the upcoming release, not much of work.

P.S. Actually, we implemented GnuPG-compatible AEAD encryption/decryption code back in 2018. However, in 2022 (3-4 years after our implementation and compatibility tests against GnuPG) OpenPGP working group produced next draft of rfc4880-bis (now called crypto-refresh), which changed AEAD format in an incompatible way (here is a reference: https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-crypto-refresh-05) , and in my opinion this is a point where unfortunate state of OpenPGP standard begin.

Nickolay, do you have a link to the relevant issue on your github? If so, please add the url to the See also field in this bug.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: gpg mime mode (6d) not compatible with thunderbird? → gpg mime mode (6d) not compatible with thunderbird (encrypted mode m)
Whiteboard: [RNP]

Sure, done!

I'm not convinced that simply adding support for this mode is the right solution.

I don't like the idea that Thunderbird might be pushed to support piece by piece of an unofficial specification.

GnuPG should not emit this kind of data that isn't supported by other implementations.

After digging more into the issue, discussing with others, and thanks to the help from Heiko,
I've learned that a wide range of implementations tolerate that packet mode.
Given this isn't specific to a newer specification, it seems acceptable to tolerate it in Thunderbird.

Hello here!
Any news about a release of this feature on thunderbird?
Currently Kmail users can't communicate GPG encrypted with Thunderbird users
Seems the fix is on RPN, but no release available?

The fix was implemented in the release v0.17.1 of RNP (which happened just few days ago) but Thunderbird didn't pick it up yet as I understand.

Thunderbird (Daily builds) updated to 0.17.1 yesterday (bug 1885353)

Depends on: 1885353

(In reply to Magnus Melin [:mkmelin] from comment #21)

Thunderbird (Daily builds) updated to 0.17.1 yesterday (bug 1885353)

Correct. That means the latest Daily builds should have the fix.

The fix is not yet available in Beta or the stable 115.x releases.

We can consider uplifting the release, but we should get some test feedback prior doing so.

The incompatibility with GnuPG is indeed unfortunate.
I had to switch to a local patched build, because I was also annoyed that I couldn't decrypt some emails.

So we should try to uplift as soon as we consider it sufficiently low risk.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: