GNU bug report logs - #14232
24.3; PGP signatures in base64 encoded mail are incompatible with some MUAs.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14232 in the body.
You can then email your comments to 14232 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mikhail Kryshen <mikhail <at> kryshen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3; PGP signatures in base64 encoded mail are incompatible with some
	MUAs.
Date: Fri, 19 Apr 2013 07:14:09 +0400

[Message part 1 (text/plain, inline)]

I use compose-mail and mml-secure-message-sign to send signed email.
For messages that contain cyrillic characters Emacs by default uses
utf-8 charset and base64 encoding.  For such messages some MUAs (Mutt,
Notmuch) report good signature and some (Sylpheed, Evolution) show bad
signature for the same message.

When quoted-printable encoding is used all MUAs show good signature
(workaround: add (utf-8 . quoted-printable) to
mm-body-charset-encoding-alist).

When base64 encoding is used, the encoded data is separated from part
boundary delimiter by a single <CR><LF> (which is part of the delimiter)
missing an additional <CR><LF> to terminate the last line of the encoded
data.  I verified by manually editing raw email files and appropriately
updating signatures that mentioned MUAs handle messages with a single
<CR><LF> between signed data and delimiter differently.  This seems to
be the cause of the problem.

From RFC 2015 "MIME Security with PGP", page 4:

   When the PGP digital signature is generated:
   [skip]
   (2)  An appropriate Content-Transfer-Encoding is then applied. Each
        line of the encoded data MUST end with the canonical <CR><LF>
        sequence.

From RFC 3156 "MIME Security with OpenPGP", page 5:

   When the OpenPGP digital signature is generated:
   [skip]
   (2)   An appropriate Content-Transfer-Encoding is then applied; see
         section 3.  In particular, line endings in the encoded data
         MUST use the canonical <CR><LF> sequence where appropriate
         (note that the canonical line ending may or may not be present
         on the last line of encoded data and MUST NOT be included in
         the signature if absent).
   [skip]
      Note: The accepted OpenPGP convention is for signed data to end
      with a <CR><LF> sequence.  Note that the <CR><LF> sequence
      immediately preceding a MIME boundary delimiter line is considered
      to be part of the delimiter in [3], 5.1.  Thus, it is not part of
      the signed data preceding the delimiter line.  An implementation
      which elects to adhere to the OpenPGP convention has to make sure
      it inserts a <CR><LF> pair on the last line of the data to be
      signed and transmitted (signed message and transmitted message
      MUST be identical).

So it seems to be correct and better for compatibility with other email
clients to terminate the last line of base64 encoded data with <CR><LF>.

--
Mikhail


In GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.6.4)
 of 2013-04-19 on home
Windowing system distributor `Fedora Project', version 11.0.11303000
Configured using:
 `configure '--host=x86_64-redhat-linux-gnu'
 '--build=x86_64-redhat-linux-gnu' '--program-prefix='
 '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
 '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
 '--datadir=/usr/share' '--includedir=/usr/include'
 '--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
 '--localstatedir=/var' '--sharedstatedir=/var/lib'
 '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus'
 '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff'
 '--with-xft' '--with-xpm' '--with-x-toolkit=gtk3' '--with-gpm=no'
 'build_alias=x86_64-redhat-linux-gnu'
 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g''

Important settings:
  value of $LANG: ru_RU.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

[Message part 2 (application/pgp-signature, inline)]

Message #8 received at 14232 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mikhail Kryshen <mikhail <at> kryshen.net>
Cc: 14232 <at> debbugs.gnu.org
Subject: Re: bug#14232: 24.3;
	PGP signatures in base64 encoded mail are incompatible with some MUAs.
Date: Fri, 19 Apr 2013 01:30:04 -0400

reassign 14232 gnus,emacs
thanks

>>>>> "Mikhail" == Mikhail Kryshen <mikhail <at> kryshen.net> writes:
> I use compose-mail and mml-secure-message-sign to send signed email.
> For messages that contain cyrillic characters Emacs by default uses
> utf-8 charset and base64 encoding.  For such messages some MUAs (Mutt,
> Notmuch) report good signature and some (Sylpheed, Evolution) show bad
> signature for the same message.

[...]
> So it seems to be correct and better for compatibility with other email
> clients to terminate the last line of base64 encoded data with <CR><LF>.

I forwarded this to the Gnus guys who know more about these issues.


        Stefan

Message #17 received at 14232-done <at> debbugs.gnu.org (full text, mbox):

From: Daiki Ueno <ueno <at> gnu.org>
To: Mikhail Kryshen <mikhail <at> kryshen.net>
Cc: 14232-done <at> debbugs.gnu.org
Subject: Re: bug#14232: 24.3;
	PGP signatures in base64 encoded mail are incompatible with some MUAs.
Date: Wed, 22 May 2013 16:22:14 +0900

Mikhail Kryshen <mikhail <at> kryshen.net> writes:

> So it seems to be correct and better for compatibility with other email
> clients to terminate the last line of base64 encoded data with <CR><LF>.

Thanks for the report and helpful information.  I've just pushed a
fix to the Gnus git master:
http://git.gnus.org/cgit/gnus.git/commit/?id=28b637bda13bd93678d2ea85f8f7fcbe7a49d862

Regards,
-- 
Daiki Ueno

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.