Your message dated Thu, 9 Jan 2014 09:03:19 +0100 with message-id <[email protected]> and subject line Re: [Pkg-gnupg-maint] Bug#733195: gnupg: quoted printable character in armor has caused the Debian Bug report #733195, regarding gnupg: quoted printable character in armor to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 733195: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733195 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: gnupg Version: 1.4.15-3 Severity: normal Dear Maintainer, Thanks for maintaining gnupg. It seems like privacy is in the news more and more these days. The main reason I'm writing is that I stumbled upon a few more clues about an old bug. Here's what I found. Someone I know uses an Apple computer to send me encrypted emails. The headers of his emails indicate he uses Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) Content-Transfer-Encoding: quoted-printable X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) I use Debian Linux, gnupg, exim4 and mutt. When I tried to decrypt his email files at the command line with $ gpg --decrypt his_email_file I expected gpg to prompt me for my pass phrase, and then decrypt his email. However, what I got was gpg: malformed CRC gpg: encrypted_mdc packet with unknown version 255 gpg: quoted printable character in armor - probably a buggy MTA has been used I found that my email client, version 1.5.21-6.4 of mutt, can work around the problem by actually changing pgp's message, without prompting me for my gpg pass phrase. Here's how I worked around the bug. run mutt, so it shows an index of the emails in your mail box select the encrypted message press the "v" key to view its mime attachments make sure the encrypted data is selected (at least for me, that's the only choice) press the "s" key to save it to a file enter a file name. The saved file should not have email headers like those starting with "From:", "To:' or "Date:". At least for me, the saved file only contains -----BEGIN PGP MESSAGE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org <encrypted looking bla bla bla> -----END PGP MESSAGE----- Using gpg on this file worked. $ gpg --decrypt file_saved_from_mutt_attachment_menu If you're like me, maybe you suspect something in the email's headers broke gpg. I checked by saving the entire email as a file from mutt's index menu, and using a text editor (vim) to manually delete the email headers, leaving only the data between -----BEGIN PGP MESSAGE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org <encrypted looking bla bla bla> -----END PGP MESSAGE----- $ gpg --decrypt file_saved_from_mutt_index_menu_and_manually_edited_to_remove_email_headers It didn't work. I still got gpg: malformed CRC gpg: encrypted_mdc packet with unknown version 255 gpg: quoted printable character in armor - probably a buggy MTA has been used If you're like me, maybe now you suspect mutt changed pgp's message. The "diff" command revealed that it did. $ diff file_saved_from_mutt_index_menu_and_manually_edited_to_remove_email_headers file_saved_from_mutt_attachment_menu 1d0 < 44,45c43,44 < CdfqLDoYwKptkg=3D=3D < =3DC1fp --- > CdfqLDoYwKptkg== > =C1fp 47d45 < The upshot is that mutt deleted three "3D"s at the end of PGP's message to change =3D=3D =3D to == = I'm surprised that mutt changed pgp's message without asking for my pass phrase. The edited PGP MESSAGE decrypted fine with $ gpg --decrypt file_saved_from_mutt_attachment_menu Similar bug reports date back as far as 2004. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=277516 https://bugzilla.mozilla.org/show_bug.cgi?id=729558 https://bugs.launchpad.net/launchpad/+bug/1520 https://bugs.launchpad.net/launchpad/+bug/894045 Maybe it has something to do with encrypting unicode data. I humbly suggest keeping this bug report open until the it's definitely fixed so my work around can save other people time, and maybe ultimately help fix the bug. It would be interesting to me to know what mutt's "s" key does from its attachment menu. Maybe gpg should do the same. Thanks, Kingsley -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnupg depends on: ii gpgv 1.4.15-1 ii libbz2-1.0 1.0.6-5 ii libc6 2.17-93 ii libreadline6 6.2-2 ii libusb-0.1-4 2:0.1.12-23.2 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages gnupg recommends: pn gnupg-curl <none> ii libldap-2.4-2 2.4.31-1+nmu2+b1 Versions of packages gnupg suggests: pn gnupg-doc <none> ii imagemagick 8:6.7.7.10-6 ii libpcsclite1 1.8.8-4+b1 ii xloadimage 4.1-21 -- no debconf information
--- End Message ---
--- Begin Message ---Hi Kingsley, On Wed, January 8, 2014 20:50, Kingsley G. Morse Jr. wrote: > Hi Thijs, > > Thank you for sharing your thoughts. > > They are much clearer than gnupg's error message. > > You very nicely asked > >> What is the bug? > > I can think of two: > > 1.) Not undoing quoted-printable encoding. > > It seems to me that gnupg might ask the > user if he or she would like it to undo > quoted-printable encoding > > Maybe this code could be copied from mutt, > and inserted where gnupg would otherwise > report > > gpg: malformed CRC > gpg: encrypted_mdc packet with unknown version 255 > gpg: quoted printable character in armor - probably a buggy > MTA has been used > > 2.) Reporting a terse and misleading error > message. > > It seems to me that more people could > protect their privacy if gnupg were easier > to use. > > I humbly suggest something more user-friendly, > like what you wrote: > > gpg: I found a malformed cyclic redundancy check (CRC) and > gpg: an encrypted_mdc packet with unknown version number of > 255. > gpg: These can happen when data is encoded in a quoted > printable format. > gpg: Would you like me to try to undo the quoted printable > format? > [y/n] ? > > Does that make sense? There is nothing GnuPG-specific in this. Nor is it a special feature of mutt. If an email is sent in any given encoding, that encoding needs to be decoded before any further processing. Any email client will do this. Mutt does, but so do pine, Thunderbird and Outlook. It also goes for any kind of document that is transferred. If you email a PDF attachment it will be base64 encoded, and PDF readers cannot read it. But that's not a problem because any email client will decode it for you. I'm unclear what we have to gain by taking a raw email message source, ignoring the specified encoding and expecting any program to deal with it nonetheless. We have these encodings to transfer things, and we have email clients that will decode them. Cheers, Thijs
--- End Message ---
