[pkg-gnupg-maint] Bug#1071552: Bug#1071552: Bug#1071552: gnupg: Please upgrade GnuPG >= 2.4.4, current GnuPG break Emacs's EasyPG

[Daniel Kahn Gillmor]

On Thu 2024-05-30 18:34:13 +0200, Andreas Metzler wrote:
> the issue report refers to two patches, one of these is already part of
> 2.2.43. The other one[1] seemed pretty straightforward to backport
> (functions moved to other files and cipher_filter_ocb instead of
> cipher_filter_aead). I would appreciate a second pair of eyes.

I wish the patch wasn't so large, even if it appears to backport
cleanly!

I confess i don't fully understand the logic around iobufs and 

I'm also more than a little distressed that the bulk of this logic and
buffer fiddling seems to be about deciding whether to compress the input
stream or not, on the basis of whether it's using SEPIDv1 (or LibrePGP's
non-standard OCB mode) vs. the deprecated, obsolete SED.

Nothing should be generating SED packets today, in 2024.  The idea that
the compression layer is going to defend against chosen ciphertext
attacks is… lacking in cryptographic rigor.

Furthermore, the idea that GnuPG will (or will not) add a compression
layer depending on the first 5 bytes of the input stream is pretty
strange.  Consider this deeply weird comparison, where depending on the
input data, the same GnuPG pipeline will compress or not compress:

```
0 dkg at alice:~$ packetlist() { printf '%s\n' "$1" | gpg --compress-algo=ZIP --encrypt -r "$PGPID" | gpg --unwrap --decrypt | gpg --list-packets; }
0 dkg at alice:~$ diff -u <(packetlist %PDFx) <(packetlist %PDF-)
gpg: encrypted with 255-bit ECDH key, ID 38024D718ABA3F3B, created 2023-12-06
      "Daniel Kahn Gillmor"
gpg: encrypted with 255-bit ECDH key, ID 38024D718ABA3F3B, created 2023-12-06
      "Daniel Kahn Gillmor"
--- /dev/fd/63	2024-05-31 17:08:37.339457042 -0400
+++ /dev/fd/62	2024-05-31 17:08:37.339457042 -0400
@@ -1,6 +1,4 @@
-# off=0 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
-:compressed packet: algo=1
-# off=2 ctb=cb tag=11 hlen=2 plen=12 new-ctb
+# off=0 ctb=cb tag=11 hlen=2 plen=12 new-ctb
 :literal data packet:
 	mode b (62), created 1717189717, name="",
 	raw data: 6 bytes
1 dkg at alice:~$
```

Seems to me like the approach that would reduce the overall amount of
complexity is to have an explicit default that does not vary choice of
compression algorithm, based on the choice of incoming cleartext, and
then to actually respect any user-specified --compress-algo, which
doesn't seem to be happening when the first five octets of the input
stream match this magic list.

Of course, i'd be happy to just rip compression out of the OpenPGP
specification entirely anyway -- people who want to compress before
encrypting have many different ways of doing it irrespective of the
OpenPGP spec.

I think we should include an autopkgtest for the gnupg2 source package
as well that explicitly ensures that future updates don't break epg.el.

I'm including it here, but i'll also put it in the autopkgtests to
ensure we don't hit this regression again.

I propose to push this test plus your patch into salsa later today and
if it passes cleanly, i'll go ahead with the upload.

   --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: emacs-epg-message-mode
Type: text/x-sh
Size: 2436 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20240531/6a3a3bf5/attachment.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20240531/6a3a3bf5/attachment.sig>