Gnus 5.10.6 problems with PGP/MIME (test cases)

Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

Background:

This problem arises using MH-E 7.85+cvs plus Gnus v5.10.6
running under GNU Emacs 21.4 on a Gentoo GNU/Linux box.

Problem (first message in attachment):

  Content-Type: text/plain; charset="us-ascii"; format=flowed

does not properly allow the GNUS 5.10.6 mml-* functions to recognize
that there is a PGP Signed message body. If the format=flowed clause is
removed, then there is no problems with this recognition. I get this ';
format=flowed' addition to the Content-Type even for PGP messages that
are encrypted by Eudora users all the time.

Problem (third message in attachment):

  Content-Type: application/pgp; x-action=sign; format=text

does not properly allow GNUS 5.10.6 mml-* function to display
the text or signature information. Note that I do understand that
this Content-Type is mentioned in RFC 2015 as being a bad idea.
However, I get this kind of Content-Type from some mutt users and
a few other Windows users.

The second message in the attachment decodes properly and will say
[[PGP Signed Part:Undecided]] until the user requests that the
signature be verified in which case it displays

  [[PGP Signed Part:Mark D Baushke <mdb@gnu.org>]] 

in the short form or

  [[PGP Signed Part:Mark D Baushke <mdb@gnu.org>]
  Signature made Wed Jan 11 16:44:25 2006 PST using DSA key ID 6B039C51
  Good signature from "Mark D Baushke <mdb@gnu.org>"
  [GNUPG:] SIG_ID 5DWnGnqCMbs+B1YcmM1o/2+BDiw 2006-01-12 1137026665
  [GNUPG:] GOODSIG 0A0EC03C6B039C51 Mark D Baushke <mdb@gnu.org>
  [GNUPG:] VALIDSIG A83FF00BF7002712D36A9F3A0A0EC03C6B039C51 2006-01-12 1137026665 0 3 0 17 2 01 A83FF00BF7002712D36A9F3A0A0EC03C6B039C51
  [GNUPG:] TRUST_FULLY
  ]

in the long form.

A similar set of problems arise when the PGP/MIME message is encrypted.
For the application/pgp form the encrypted Content-Type generated by
mutt looks like this:

  Content-Type: application/pgp; x-action=encrypt; format=text

Please let me know if you have any questions.

	Thanks,
	-- Mark

The shell archive below contains an mbox-style formatted file with two
messages. The messages are identical except that one

#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.2.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 2006-01-11 16:58 PST by <mdb@gnu.org>.
# Source directory was `/home/m/mdb'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode       name
# ------ ---------- ------------------------------------------
#   1606 -rw-r--r-- /homes/mdb/gnus.msg
#
save_IFS="${IFS}"
IFS="${IFS}:"
gettext_dir=FAILED
locale_dir=FAILED
first_param="$1"
for dir in $PATH
do
  if test "$gettext_dir" = FAILED && test -f $dir/gettext \
     && ($dir/gettext --version >/dev/null 2>&1)
  then
    set `$dir/gettext --version 2>&1`
    if test "$3" = GNU
    then
      gettext_dir=$dir
    fi
  fi
  if test "$locale_dir" = FAILED && test -f $dir/shar \
     && ($dir/shar --print-text-domain-dir >/dev/null 2>&1)
  then
    locale_dir=`$dir/shar --print-text-domain-dir`
  fi
done
IFS="$save_IFS"
if test "$locale_dir" = FAILED || test "$gettext_dir" = FAILED
then
  echo=echo
else
  TEXTDOMAINDIR=$locale_dir
  export TEXTDOMAINDIR
  TEXTDOMAIN=sharutils
  export TEXTDOMAIN
  echo="$gettext_dir/gettext -s"
fi
if touch -am -t 200112312359.59 $$.touch >/dev/null 2>&1 && test ! -f 200112312359.59 -a -f $$.touch; then
  shar_touch='touch -am -t $1$2$3$4$5$6.$7 "$8"'
elif touch -am 123123592001.59 $$.touch >/dev/null 2>&1 && test ! -f 123123592001.59 -a ! -f 123123592001.5 -a -f $$.touch; then
  shar_touch='touch -am $3$4$5$6$1$2.$7 "$8"'
elif touch -am 1231235901 $$.touch >/dev/null 2>&1 && test ! -f 1231235901 -a -f $$.touch; then
  shar_touch='touch -am $3$4$5$6$2 "$8"'
else
  shar_touch=:
  echo
  $echo 'WARNING: not restoring timestamps.  Consider getting and'
  $echo "installing GNU \`touch', distributed in GNU File Utilities..."
  echo
fi
rm -f 200112312359.59 123123592001.59 123123592001.5 1231235901 $$.touch
#
if mkdir _sh14108; then
  $echo 'x -' 'creating lock directory'
else
  $echo 'failed to create lock directory'
  exit 1
fi
# ============= /homes/mdb/gnus.msg ==============
if test ! -d '/homes'; then
  $echo 'x -' 'creating directory' '/homes'
  mkdir '/homes'
fi
if test ! -d '/homes/mdb'; then
  $echo 'x -' 'creating directory' '/homes/mdb'
  mkdir '/homes/mdb'
fi
if test -f '/homes/mdb/gnus.msg' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING '/homes/mdb/gnus.msg' '(file already exists)'
else
  $echo 'x -' extracting '/homes/mdb/gnus.msg' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > '/homes/mdb/gnus.msg' &&
XFrom mdb@gnu.org Wed Jan 11 16:45:06 2006
To: mdb@gnu.org
XFrom: "Mark D. Baushke" <mdb@gnu.org>
Subject: test pgp message
Content-Type: text/plain; charset="us-ascii"; format=flowed
Mime-Version: 1.0
Date: Wed, 11 Jan 2006 16:45:06 -0800
Message-ID: <13570.1137026706@fencepost.gnu.org>
X
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
X
This is a test.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
X
iD8DBQFDxaZpCg7APGsDnFERAgolAJ9+VbmaXTgWiMTEl4Y2gSQOGF3zHQCfR7MZ
tns6uRALb5LuMSIQMdbm6E4=
=SycC
-----END PGP SIGNATURE-----
X
XFrom mdb@gnu.org Wed Jan 11 16:45:06 2006
To: mdb@gnu.org
XFrom: "Mark D. Baushke" <mdb@gnu.org>
Subject: test pgp message
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Date: Wed, 11 Jan 2006 16:45:06 -0800
Message-ID: <13570.1137026706@fencepost.gnu.org>
X
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
X
This is a test.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
X
iD8DBQFDxaZpCg7APGsDnFERAgolAJ9+VbmaXTgWiMTEl4Y2gSQOGF3zHQCfR7MZ
tns6uRALb5LuMSIQMdbm6E4=
=SycC
-----END PGP SIGNATURE-----
X
XFrom mdb@gnu.org Wed Jan 11 16:45:06 2006
To: mdb@gnu.org
XFrom: "Mark D. Baushke" <mdb@gnu.org>
Subject: test pgp message
Content-Type: application/pgp; x-action=sign; format=text
Mime-Version: 1.0
Date: Wed, 11 Jan 2006 16:45:06 -0800
Message-ID: <13570.1137026706@fencepost.gnu.org>
X
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
X
This is a test.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
X
iD8DBQFDxaZpCg7APGsDnFERAgolAJ9+VbmaXTgWiMTEl4Y2gSQOGF3zHQCfR7MZ
tns6uRALb5LuMSIQMdbm6E4=
=SycC
-----END PGP SIGNATURE-----
X
SHAR_EOF
  (set 20 06 01 11 16 57 41 '/homes/mdb/gnus.msg'; eval "$shar_touch") &&
  chmod 0644 '/homes/mdb/gnus.msg' ||
  $echo 'restore of' '/homes/mdb/gnus.msg' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo '/homes/mdb/gnus.msg:' 'MD5 check failed'
7c902d121e94e6df39e643e77ba4fb1c  /homes/mdb/gnus.msg
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < '/homes/mdb/gnus.msg'`"
    test 1606 -eq "$shar_count" ||
    $echo '/homes/mdb/gnus.msg:' 'original size' '1606,' 'current size' "$shar_count!"
  fi
fi
rm -fr _sh14108
exit 0


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Reiner Steib]

On Thu, Jan 12 2006, Mark D. Baushke wrote:

> Background:
>
> This problem arises using MH-E 7.85+cvs plus Gnus v5.10.6
> running under GNU Emacs 21.4 on a Gentoo GNU/Linux box.
>
> Problem (first message in attachment):
>
>   Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> does not properly allow the GNUS 5.10.6 mml-* functions to recognize
> that there is a PGP Signed message body. 

In my setup with current CVS Gnus (No Gnus), I get:

,----
| Content-Type: text/plain; charset="us-ascii"; format=flowed
| Message-ID: <13570.1137026706@fencepost.gnu.org>
| 
| [[PGP Signed Part:Undecided]]
| This is a test.
| [[End of PGP Signed Part]]
`----

... and after pressing the button:

,----
| [[PGP Signed Part:Mark D Baushke <mdb@gnu.org>
| Untrusted, Fingerprint: A83F F00B F700 2712 D36A 9F3A 0A0E C03C 6B03 9C51]]
| This is a test.
| [[End of PGP Signed Part]]
`----

When using plain Gnus 5.10.7 (not released, v5-10 branch = Gnus 5.11
in Emacs CVS) without customizations, I get not buttons and `W s'
(gnus-summary-force-verify-and-decrypt) doesn't work:

,----
| -----BEGIN PGP SIGNED MESSAGE-----
| Hash: SHA1
| 
| This is a test.
| -----BEGIN PGP SIGNATURE-----
| Version: GnuPG v1.2.6 (GNU/Linux)
| 
| iD8DBQFDxaZpCg7APGsDnFERAgolAJ9+VbmaXTgWiMTEl4Y2gSQOGF3zHQCfR7MZ
| tns6uRALb5LuMSIQMdbm6E4=
| =SycC
| -----END PGP SIGNATURE-----
`----

I didn't have time to figure out whether No Gnus or my customizations
make the difference.  But it's a bug in Gnus that `W s' doesn't work
in v5-10.  Okay, I found this in our ChangeLog:

,----[ lisp/ChangeLog (trunk) ]
| 2004-10-06  Katsumi Yamaoka  <yamaoka@jpl.org>
| 
| 	* mm-uu.el (mm-uu-dissect): Allow optional arg.
| 	(mm-uu-dissect-text-parts): New function.
| 
| 	* gnus-art.el (gnus-display-mime): Use mm-uu-dissect-text-parts to
| 	dissect text parts.
| 
| 	* gnus-sum.el (gnus-summary-insert-subject): Remove redundant setq.
| 	(gnus-summary-force-verify-and-decrypt): Revert 2004-08-18 change.
| 
| 	* mm-decode.el (mm-dissect-singlepart): Revert 2004-08-18 change.
| 
| [...]
| 
| 2004-08-18  Florian Weimer  <fw@deneb.enyo.de>
| 
| 	* gnus-sum.el (gnus-summary-force-verify-and-decrypt): Bind
| 	`mm-fill-flowed'.
| 
| 	* mm-decode.el (mm-dissect-singlepart): Check it.
`----

Katsumi, shouldn't we include your changes in v5-10?

> Problem (third message in attachment):
>
>   Content-Type: application/pgp; x-action=sign; format=text
>
> does not properly allow GNUS 5.10.6 mml-* function to display
> the text or signature information. Note that I do understand that
> this Content-Type is mentioned in RFC 2015 as being a bad idea.
> However, I get this kind of Content-Type from some mutt users and
> a few other Windows users.

I don't know.  Maybe someone else can comment on this?

> The second message in the attachment decodes properly and will say
> [[PGP Signed Part:Undecided]] 

Your second message (w/o format=flowed) works in both setups.

> The shell archive below contains an mbox-style formatted file with two
> messages. [...]

The shell archive contained hard coded directories like this:
>   mkdir '/homes/mdb'

For the Gnus list, it's probably better to send the mbox file as
gzipped attachment (when sending inline, the mailing list software
might mangle whitespace or line endings).  Maybe you could resend your
test cases mbox file to make it easier for others to investigate it?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: multipart/mixed; boundary="=-=-=", Size: 2410 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --=-=-=

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> For the Gnus list, it's probably better to send the mbox file as
> gzipped attachment (when sending inline, the mailing list software
> might mangle whitespace or line endings).  Maybe you could resend your
> test cases mbox file to make it easier for others to investigate it?

Attached below.

	-- Mark


- --=-=-=
Content-Disposition: inline; filename=gnus.msg
Content-Transfer-Encoding: quoted-printable
Content-Description: Testcase mbox file

From=20mdb@gnu.org Wed Jan 11 16:45:06 2006
To: mdb@gnu.org
From: "Mark D. Baushke" <mdb@gnu.org>
Subject: test pgp message
Content-Type: text/plain; charset=3D"us-ascii"; format=3Dflowed
Mime-Version: 1.0
Date: Wed, 11 Jan 2006 16:45:06 -0800
Message-ID: <13570.1137026706@fencepost.gnu.org>

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is a test.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDxaZpCg7APGsDnFERAgolAJ9+VbmaXTgWiMTEl4Y2gSQOGF3zHQCfR7MZ
tns6uRALb5LuMSIQMdbm6E4=3D
=3DSycC
=2D----END PGP SIGNATURE-----

From=20mdb@gnu.org Wed Jan 11 16:45:06 2006
To: mdb@gnu.org
From: "Mark D. Baushke" <mdb@gnu.org>
Subject: test pgp message
Content-Type: text/plain; charset=3D"us-ascii"
Mime-Version: 1.0
Date: Wed, 11 Jan 2006 16:45:06 -0800
Message-ID: <13570.1137026706@fencepost.gnu.org>

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is a test.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDxaZpCg7APGsDnFERAgolAJ9+VbmaXTgWiMTEl4Y2gSQOGF3zHQCfR7MZ
tns6uRALb5LuMSIQMdbm6E4=3D
=3DSycC
=2D----END PGP SIGNATURE-----

From=20mdb@gnu.org Wed Jan 11 16:45:06 2006
To: mdb@gnu.org
From: "Mark D. Baushke" <mdb@gnu.org>
Subject: test pgp message
Content-Type: application/pgp; x-action=3Dsign; format=3Dtext
Mime-Version: 1.0
Date: Wed, 11 Jan 2006 16:45:06 -0800
Message-ID: <13570.1137026706@fencepost.gnu.org>

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is a test.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDxaZpCg7APGsDnFERAgolAJ9+VbmaXTgWiMTEl4Y2gSQOGF3zHQCfR7MZ
tns6uRALb5LuMSIQMdbm6E4=3D
=3DSycC
=2D----END PGP SIGNATURE-----


- --=-=-=--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFDyGi7Cg7APGsDnFERAhgsAKClK5EGxq1xlCLN6/yFqlfMmLTr/QCeM6fx
wMqa/jjOcP0Aq9dbsUVsOR4=
=rEI5
-----END PGP SIGNATURE-----

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

>>>>> In <v9y81jn23c.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib <reinersteib+gmane@imap.cc> wrote:

>| 2004-10-06  Katsumi Yamaoka  <yamaoka@jpl.org>
>| 2004-08-18  Florian Weimer  <fw@deneb.enyo.de>

> Katsumi, shouldn't we include your changes in v5-10?

Yes, I'll do it at the beginning of next week.  Thank you for
digging it up.

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

>>>>> In <b4mmzhyx3d9.fsf@jpl.org> Katsumi Yamaoka wrote:

>>>>>> In <v9y81jn23c.fsf@marauder.physik.uni-ulm.de>
>>>>>>	Reiner Steib <reinersteib+gmane@imap.cc> wrote:

>>| 2004-10-06  Katsumi Yamaoka  <yamaoka@jpl.org>
>>| 2004-08-18  Florian Weimer  <fw@deneb.enyo.de>

>> Katsumi, shouldn't we include your changes in v5-10?

> Yes, I'll do it at the beginning of next week.  Thank you for
> digging it up.

Fixed in CVS.  The patch attached below is for Gnus 5.10.6:


[-- Attachment #2: gnus-5.10.6.diff.gz --]
[-- Type: application/x-gzip, Size: 1620 bytes --]

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Katsumi,

Hmmm... 

I am not seeing any difference after I patch the
gnus-art.el and mm-uu.el files and byte-compile
them.

The message with the

   Content-Type: text/plain; charset="us-ascii"; format=flowed

still shows the various PGP markers:

'-----BEGIN PGP SIGNED MESSAGE-----', 
<the message>
'-----BEGIN PGP SIGNATURE-----' 
<the base64 signature block>
'-----END PGP SIGNATURE-----'

instead of actually recognizing that the message is a
signed text and should be desplayed as:

 [[PGP Signed Part:Undecided]]
  This is a test.
  
 [[End of PGP Signed Part]]
 
or, after the button has been executed displayed as:


  [[PGP Signed Part:Mark D Baushke <mdb@gnu.org>]]
  This is a test.
  
  [[End of PGP Signed Part]]


The second message works fine and the third message
also shows no differences before and after the patch.

	-- Mark

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> >>>>> In <b4mmzhyx3d9.fsf@jpl.org> Katsumi Yamaoka wrote:
> 
> >>>>>> In <v9y81jn23c.fsf@marauder.physik.uni-ulm.de>
> >>>>>>	Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> 
> >>| 2004-10-06  Katsumi Yamaoka  <yamaoka@jpl.org>
> >>| 2004-08-18  Florian Weimer  <fw@deneb.enyo.de>
> 
> >> Katsumi, shouldn't we include your changes in v5-10?
> 
> > Yes, I'll do it at the beginning of next week.  Thank you for
> > digging it up.
> 
> Fixed in CVS.  The patch attached below is for Gnus 5.10.6:
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFDyz76Cg7APGsDnFERAnttAJ9JuROfaxaUYD00Wi0HCX6/y73nPACfUCVd
m+8Twc6mzzLDAZnFtfgmza8=
=wwWz
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

>>>>> In <26554.1137393402@juniper.net> Mark D. Baushke wrote:

> Hmmm... 

> I am not seeing any difference after I patch the
> gnus-art.el and mm-uu.el files and byte-compile
> them.

In fact I don't know how they work with MH-E + Gnus, but I guess
they might work differently from Gnus.

> The message with the

>    Content-Type: text/plain; charset="us-ascii"; format=flowed

> still shows the various PGP markers:

> '-----BEGIN PGP SIGNED MESSAGE-----', 
> <the message>
> '-----BEGIN PGP SIGNATURE-----' 
> <the base64 signature block>
> '-----END PGP SIGNATURE-----'

> instead of actually recognizing that the message is a
> signed text and should be desplayed as:

>  [[PGP Signed Part:Undecided]]
>   This is a test.

>  [[End of PGP Signed Part]]

> or, after the button has been executed displayed as:

>   [[PGP Signed Part:Mark D Baushke <mdb@gnu.org>]]
>   This is a test.

>   [[End of PGP Signed Part]]

I verified that the patched Gnus 5.10.6 works (it is Gnus, not
MH-E + Gnus).  Could you try the following Lisp form in the
buffer which visits the first (raw) message?

(mm-uu-dissect-text-parts (mm-dissect-buffer nil t))

It is expected that you will see "multipart/signed" in the
result.  If not, I need to try MH-E + Gnus.

> The second message works fine and the third message
> also shows no differences before and after the patch.

To make sure, I attach ``the first message'' that I use:


[-- Attachment #2: 1.gz --]
[-- Type: application/x-gzip, Size: 405 bytes --]

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

>>>>> In <b4mek38ioxo.fsf@jpl.org> Katsumi Yamaoka wrote:

> In fact I don't know how they work with MH-E + Gnus, but I guess
> they might work differently from Gnus.

Bingo!  I found mh-mime.el uses the mm- functions directly and
realized the mh-mime-display functions should be modified as
follows:

--8<---------------cut here---------------start------------->8---
--- mh-mime.el~	2006-01-15 21:49:23 +0000
+++ mh-mime.el	2006-01-16 08:39:53 +0000
@@ -921,7 +921,10 @@
             ;; If needed dissect the current buffer
             (if pre-dissected-handles
                 (setq handles pre-dissected-handles)
-              (setq handles (or (mm-dissect-buffer nil) (mm-uu-dissect)))
+              (if (setq handles (mm-dissect-buffer nil))
+                  (when (fboundp 'mm-uu-dissect-text-parts)
+                    (mm-uu-dissect-text-parts handles))
+                (setq handles (mm-uu-dissect)))
               (setf (mh-mime-handles (mh-buffer-data))
                     (mm-merge-handles handles
                                       (mh-mime-handles (mh-buffer-data))))
--8<---------------cut here---------------end--------------->8---

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

>>>>> In <b4mzmlwh8eg.fsf@jpl.org> Katsumi Yamaoka wrote:

> Bingo!  I found mh-mime.el uses the mm- functions directly and
> realized the mh-mime-display functions should be modified as
> follows:

A similar change seems to be required to mh-mm-inline-message as
well.  Here's a new patch:

--8<---------------cut here---------------start------------->8---
--- mh-mime.el~	2006-01-15 21:49:23 +0000
+++ mh-mime.el	2006-01-16 08:58:50 +0000
@@ -921,7 +921,10 @@
             ;; If needed dissect the current buffer
             (if pre-dissected-handles
                 (setq handles pre-dissected-handles)
-              (setq handles (or (mm-dissect-buffer nil) (mm-uu-dissect)))
+              (if (setq handles (mm-dissect-buffer nil))
+                  (when (fboundp 'mm-uu-dissect-text-parts)
+                    (mm-uu-dissect-text-parts handles))
+                (setq handles (mm-uu-dissect)))
               (setf (mh-mime-handles (mh-buffer-data))
                     (mm-merge-handles handles
                                       (mh-mime-handles (mh-buffer-data))))
@@ -1477,8 +1480,11 @@
         (mh-mime-display
          (or (gethash handle (mh-mime-handles-cache (mh-buffer-data)))
              (setf (gethash handle (mh-mime-handles-cache (mh-buffer-data)))
-                   (let ((handles (or (mm-dissect-buffer nil)
-                                      (mm-uu-dissect))))
+                   (let ((handles (mm-dissect-buffer nil)))
+                     (if handles
+                         (when (fboundp 'mm-uu-dissect-text-parts)
+                           (mm-uu-dissect-text-parts handles))
+                       (setq handles (mm-uu-dissect)))
                      (setf (mh-mime-handles (mh-buffer-data))
                            (mm-merge-handles
                             handles (mh-mime-handles (mh-buffer-data))))
--8<---------------cut here---------------end--------------->8---

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Bill Wohler]

Katsumi Yamaoka <yamaoka@jpl.org> wrote:

> >>>>> In <b4mzmlwh8eg.fsf@jpl.org> Katsumi Yamaoka wrote:
> 
> > Bingo!  I found mh-mime.el uses the mm- functions directly and
> > realized the mh-mime-display functions should be modified as
> > follows:
> 
> A similar change seems to be required to mh-mm-inline-message as
> well.  Here's a new patch:

Katsumi, thanks very much for investigating. Mark, can you please apply
Katsumi's patch and check it in if it resolves your problem? Thanks.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bill Wohler <wohler@newt.com> writes:

> Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> 
> > >>>>> In <b4mzmlwh8eg.fsf@jpl.org> Katsumi Yamaoka wrote:
> > 
> > > Bingo!  I found mh-mime.el uses the mm- functions directly and
> > > realized the mh-mime-display functions should be modified as
> > > follows:
> > 
> > A similar change seems to be required to mh-mm-inline-message as
> > well.  Here's a new patch:

Katsumi, thank you very much for your patch.

> 
> Katsumi, thanks very much for investigating. Mark, can you please apply
> Katsumi's patch and check it in if it resolves your problem? Thanks.

It does fix the problem for message 1. I have checked in the change for
MH-E. I referenced SF#1273521, but I do not believe that request is
really closed yet as MH-E probably needs more help to support generating
text=flowed messages.

Note that the message 3:

  Content-Type: application/pgp; x-action=sign; format=text

is still not really being recognized as a signed message. I do not know
if there is any way to get GNUS to help us with that problem or not.

	Thanks,
	-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFDy/irCg7APGsDnFERAnYLAJ9oQenaEIKhx4pTKmwXUPWcrgt8MgCgspNZ
c4cqkI9K1Gj9b1tw80xyqbA=
=j02O
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

>>>>> In <73630.1137440939@juniper.net> Mark D. Baushke wrote:

> Note that the message 3:

>   Content-Type: application/pgp; x-action=sign; format=text

> is still not really being recognized as a signed message. I do not know
> if there is any way to get GNUS to help us with that problem or not.

Well, where is such a content-type defined?  I couldn't find it
out in the internet ("format=fixed" and "format=flowed" are
described in RFC2646 but "format=text" isn't).

Does "format=text" mean a message necessarily contains text that
can be displayed regardless of a type (which is "application/pgp"
in that case)? ...[1]
Or, does it hold good only in the case where a type is
"application/pgp"? ...[2]

If the answer for [1] is yes, we can do the following:

Add "application/pgp" to the variables `mm-automatic-display'
and `mm-inlined-types'.  For an experiment, you can do it as
follows:

(push "application/pgp" mm-automatic-display)
(push "application/pgp" mm-inlined-types)

And modify mm-uu.el.  Here's a patch, which can be applied to
both Gnus 5.10.6 and No Gnus:


[-- Attachment #2: mm-uu.el.diff.gz --]
[-- Type: application/x-gzip, Size: 281 bytes --]

[-- Attachment #3: Type: text/plain, Size: 25 bytes --]


The message 3 is here:


[-- Attachment #4: 3.gz --]
[-- Type: application/x-gzip, Size: 399 bytes --]

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> > Note that the message 3:
> 
> >   Content-Type: application/pgp; x-action=sign; format=text
> 
> > is still not really being recognized as a signed message. I do not know
> > if there is any way to get GNUS to help us with that problem or not.
> 
> Well, where is such a content-type defined?  I couldn't find it
> out in the internet ("format=fixed" and "format=flowed" are
> described in RFC2646 but "format=text" isn't).

http://www.ipa.go.jp/security/rfc/RFC3156EN.html says:

   Work on integrating PGP (Pretty Good Privacy) with MIME [3]
   (including the since withdrawn "application/pgp" content type) prior
   to RFC 2015 suffered from a number of problems, the most significant
   of which is the inability to recover signed message bodies without
   parsing data structures specific to PGP.
   ...
   [3]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part Two: Media Types", RFC 2046, November
         1996.

The problem is that the Mutt 'USING PGP FROM WITHIN MUTT' document

  http://www.mutt.org/doc/PGP-Notes.txt

still specifies this withdrawn applications/pgp content-type and it
appears to be a populate mechanism for mutt users to add pgp support.

> Does "format=text" mean a message necessarily contains text that
> can be displayed regardless of a type (which is "application/pgp"
> in that case)? ...[1]
> Or, does it hold good only in the case where a type is
> "application/pgp"? ...[2]
> If the answer for [1] is yes, we can do the following:

As near as I can tell, both

    Content-Type: applciation/pgp; x-action=sign; format=text
and
    Content-Type: application/pgp; x-action=encrypt; format=text

which are the two most common Mutt user PGP content types I see may be
treated as if this where what was used:

  Content-Type: text/plain

Doing this allows me to be prompted for an encrypted PGP message or see
the signature buttons for other PGP messages.

> 
> Add "application/pgp" to the variables `mm-automatic-display'
> and `mm-inlined-types'.  For an experiment, you can do it as
> follows:
> 
> (push "application/pgp" mm-automatic-display)
> (push "application/pgp" mm-inlined-types)

I tried this, but something odd happened...

> And modify mm-uu.el.  Here's a patch, which can be applied to
> both Gnus 5.10.6 and No Gnus:

Hmmm... yes, your patch to mm-uu.el works to fix the problem.

	Thank you!
	-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFDzLI7Cg7APGsDnFERAhPxAKClP9pdKFLguAIav1ZXuRDJYpJDxACgrSCt
lLpSgwUdg761yhsZ8KSyPLg=
=rU6r
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

>>>>> In <31430.1137488443@juniper.net> Mark D. Baushke wrote:

>>>   Content-Type: application/pgp; x-action=sign; format=text

>> Well, where is such a content-type defined?

> http://www.ipa.go.jp/security/rfc/RFC3156EN.html says:

>    Work on integrating PGP (Pretty Good Privacy) with MIME [3]
>    (including the since withdrawn "application/pgp" content type) prior
>    to RFC 2015 suffered from a number of problems, the most significant
>    of which is the inability to recover signed message bodies without
>    parsing data structures specific to PGP.
>    ...
>    [3]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
>          Extensions (MIME) Part Two: Media Types", RFC 2046, November
>          1996.

> The problem is that the Mutt 'USING PGP FROM WITHIN MUTT' document

>   http://www.mutt.org/doc/PGP-Notes.txt

> still specifies this withdrawn applications/pgp content-type and it
> appears to be a populate mechanism for mutt users to add pgp support.

Ok.  Gnus does anything particularly if they are used.  And what
is better, making Gnus support it will give nobody trouble, I
think.  So, I've modified mm-uu.el so as to recognize
applications/pgp message as text in the Gnus CVS repository.
I've also modified the default values for mm-inlined-types and
mm-uu-dissect-text-parts.

The following is for Gnus 5.10.6, it requires that the patch I
sent in <b4m4q45f1kf.fsf@jpl.org> has been applied in advance.


[-- Attachment #2: gnus-5.10.6.diff-2.gz --]
[-- Type: application/x-gzip, Size: 689 bytes --]

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Katsumi,

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> >>>>> In <31430.1137488443@juniper.net> Mark D. Baushke wrote:
> 
> >>>   Content-Type: application/pgp; x-action=sign; format=text
> 
> >> Well, where is such a content-type defined?
> 
> > http://www.ipa.go.jp/security/rfc/RFC3156EN.html says:
> 
> >    Work on integrating PGP (Pretty Good Privacy) with MIME [3]
> >    (including the since withdrawn "application/pgp" content type) prior
> >    to RFC 2015 suffered from a number of problems, the most significant
> >    of which is the inability to recover signed message bodies without
> >    parsing data structures specific to PGP.
> >    ...
> >    [3]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
> >          Extensions (MIME) Part Two: Media Types", RFC 2046, November
> >          1996.
> 
> > The problem is that the Mutt 'USING PGP FROM WITHIN MUTT' document
> 
> >   http://www.mutt.org/doc/PGP-Notes.txt
> 
> > still specifies this withdrawn applications/pgp content-type and it
> > appears to be a populate mechanism for mutt users to add pgp support.
> 
> Ok.  Gnus does anything particularly if they are used.  And what
> is better, making Gnus support it will give nobody trouble, I
> think.  So, I've modified mm-uu.el so as to recognize
> applications/pgp message as text in the Gnus CVS repository.
> I've also modified the default values for mm-inlined-types and
> mm-uu-dissect-text-parts.
> 
> The following is for Gnus 5.10.6, it requires that the patch I
> sent in <b4m4q45f1kf.fsf@jpl.org> has been applied in advance.

Okay, I backed out the mm-uu.el patch sent in <b4m3bjnwbmi.fsf@jpl.org>.
Then I applied the <b4mirsjjfc1.fsf@jpl.org> patch.

Everything looks good with your patches.

How should we note these fixes in our NEWS file when we release MH-E
7.90? Should we point folks at a union of the two patches to
GNUS-5.10.6, or will there be an official gnus-5.10.7 sometime in the
future for folks to use?

While I have your attention about encrypted and signed e-mail
messages...

I will note that I have one private patch to gnus-5.10.6 that I reported
to bugs@gnus.org on 2005-02-06 in <75396.1107736662@juniper.net> in
which I wrote:

| I am indirectly using the pgg-gpg-encrypt-region function when sending
| gpg encrypted e-mail via the MH-E front-end under GNU Emacs 21.3.
| 
| The e-mail is arriving with DOS line endings which is getting me some
| complaints from my recipients who do not like ^M at the end of all of
| their lines.
| 
| The solution would seem to be to tell gpg that the messages are in
| textmode via the --textmode option which allows the OpenPGP compatible
| recipient program to insert whatever line-endings it wishes to consider
| for 'text' mode. Of course, if someone is encrypting a binary
| attachment, the use of '--textmode' would not be appropriate.
| 
| When I patch my gnus 5.10.6 distribution as included below, the problem
| goes away for text messages. This patch is NOT recommended for binary
| data.
| 
| I do not know how you will want to fix this problem in the real GNUS
| distribution, but I think there should at least be some mechanism for a
| function that is calling pgg-gpg-encrypt-region to specify that
| --textmode should be passed to gpg.

- --- gnus-5.10.6/lisp/pgg-gpg.el~ 2003-12-07 07:40:52.000000000 -0800
+++ gnus-5.10.6/lisp/pgg-gpg.el     2005-02-06 16:14:47.478961000 -0800
@@ -155,7 +155,7 @@
             pgg-gpg-user-id)))
         (args
          (append
- -          (list "--batch" "--armor" "--always-trust" "--encrypt")
+          (list "--batch" "--textmode" "--armor" "--always-trust" "--encrypt")
           (if sign (list "--sign" "--local-user" pgg-gpg-user-id))
           (if recipients
               (apply #'nconc


I do not see any changes in how pgg-gpg-encrypt-region is handled in the
CVS version of gnus.

It would be nice to put this issue to bed.

	Thank you,
	-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFDzTTSCg7APGsDnFERAgA3AKDLw4Yar1YxQHBc4gJxwefJ+fBeswCgvJey
L3kEBEuIgLeY0p6VM7GATVQ=
=CX10
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 2644 bytes --]

>>>>> In <85906.1137521874@juniper.net> Mark D. Baushke wrote:

> How should we note these fixes in our NEWS file when we release MH-E
> 7.90? Should we point folks at a union of the two patches to
> GNUS-5.10.6, or will there be an official gnus-5.10.7 sometime in the
> future for folks to use?

This is a common problem to Gnus users and MH-E plus Gnus users.
It is because those who use not-patched-Gnus 5.10.6 cannot also
see those messages satisfactorily as well as people who use MH-E
plus not-patched-Gnus 5.10.6.  I'm not positive to release the
patch especially for Gnus 5.10.6 since improvements done
afterward are not only this and people for whom it is necessary
have ways to obtain the latest Gnus (from CVS or ftp.gnus.org).
I know there are those who hate using softwares under
development of course, but don't know when Gnus is completed. ;-)
Anyway, it is MH-E people who decide how to deal with this.

This problem might be solved when Emacs 22.1 including Gnus 5.11
(aka 5.10.7) is sooner or later released (at that time 5.10.7
will probably be released as well), though.

> While I have your attention about encrypted and signed e-mail
> messages...

> I will note that I have one private patch to gnus-5.10.6 that I reported
> to bugs@gnus.org on 2005-02-06 in <75396.1107736662@juniper.net> in
> which I wrote:

>| I am indirectly using the pgg-gpg-encrypt-region function when sending
>| gpg encrypted e-mail via the MH-E front-end under GNU Emacs 21.3.
>| 
>| The e-mail is arriving with DOS line endings which is getting me some
>| complaints from my recipients who do not like ^M at the end of all of
>| their lines.

Confirmed.  Gnus users will never notice this because the
decription code uses the raw-text-dos coding system (which
converts CRLF to LF) when reading decrypted date from a temp
file.

> --- gnus-5.10.6/lisp/pgg-gpg.el~ 2003-12-07 07:40:52.000000000 -0800
> +++ gnus-5.10.6/lisp/pgg-gpg.el     2005-02-06 16:14:47.478961000 -0800
> @@ -155,7 +155,7 @@
>              pgg-gpg-user-id)))
>          (args
>           (append
> -          (list "--batch" "--armor" "--always-trust" "--encrypt")
> +          (list "--batch" "--textmode" "--armor" "--always-trust" "--encrypt")
>            (if sign (list "--sign" "--local-user" pgg-gpg-user-id))
>            (if recipients
>                (apply #'nconc

Doesn't the patch cause inconvenience to DOS users?  If many DOS
mailers don't use the --textmode option to decrypt messages, we
might be complained about that of LF, not CRLF, contrarily.  I
cannot verify this with DOS machines, sorry.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> >>>>> In <85906.1137521874@juniper.net> Mark D. Baushke wrote:
> 
> > How should we note these fixes in our NEWS
> > file when we release MH-E 7.90? Should we
> > point folks at a union of the two patches to
> > GNUS-5.10.6, or will there be an official
> > gnus-5.10.7 sometime in the future for folks
> > to use?
> 
> This is a common problem to Gnus users and MH-E
> plus Gnus users. It is because those who use
> not-patched-Gnus 5.10.6 cannot also see those
> messages satisfactorily as well as people who
> use MH-E plus not-patched-Gnus 5.10.6. I'm not
> positive to release the patch especially for
> Gnus 5.10.6 since improvements done afterward
> are not only this and people for whom it is
> necessary have ways to obtain the latest Gnus
> (from CVS or ftp.gnus.org). I know there are
> those who hate using softwares under development
> of course, but don't know when Gnus is
> completed. ;-) Anyway, it is MH-E people who
> decide how to deal with this.

Okay. I'll let Bill choose how he wants to notate
this. A copy of your patches to let the patched
MH-E deal with things has been added to the
https://sourceforge.net/tracker/index.php?func=detail&aid=1273521&group_id=13357&atid=363357

https://sourceforge.net/tracker/download.php?group_id=13357&atid=363357&file_id=163858&aid=1273521

> This problem might be solved when Emacs 22.1
> including Gnus 5.11 (aka 5.10.7) is sooner or
> later released (at that time 5.10.7 will
> probably be released as well), though.

Sure. We are working hard to make MH-E 8.x
available for the Emacs 22.1 release... but the
next release of MH-E will be the first beta MH-E
7.90.
 
> > While I have your attention about encrypted
> > and signed e-mail messages...
> 
> > I will note that I have one private patch to
> > gnus-5.10.6 that I reported to bugs@gnus.org
> > on 2005-02-06 in
> > <75396.1107736662@juniper.net> in which I
> > wrote:
> 
> >| I am indirectly using the
> >| pgg-gpg-encrypt-region function when sending
> >| gpg encrypted e-mail via the MH-E front-end
> >| under GNU Emacs 21.3.
> >| 
> >| The e-mail is arriving with DOS line endings
> >| which is getting me some complaints from my
> >| recipients who do not like ^M at the end of
> >| all of their lines.
> 
> Confirmed. Gnus users will never notice this
> because the decription code uses the
> raw-text-dos coding system (which converts CRLF
> to LF) when reading decrypted date from a temp
> file.

Yes, but do non-Gnus users notice this?

> > --- gnus-5.10.6/lisp/pgg-gpg.el~ 2003-12-07 07:40:52.000000000 -0800
> > +++ gnus-5.10.6/lisp/pgg-gpg.el     2005-02-06 16:14:47.478961000 -0800
> > @@ -155,7 +155,7 @@
> >              pgg-gpg-user-id)))
> >          (args
> >           (append
> > -          (list "--batch" "--armor" "--always-trust" "--encrypt")
> > +          (list "--batch" "--textmode" "--armor" "--always-trust" "--encrypt")
> >            (if sign (list "--sign" "--local-user" pgg-gpg-user-id))
> >            (if recipients
> >                (apply #'nconc
> 
> Doesn't the patch cause inconvenience to DOS users?  

It should work without any problems to DOS users.

What is happening is that --textmode tells GnuPG
to send a literal Data Packet (Tag 11) with a data
format of 't' (0x74) to specify that the packet
contains text data and thus may need line ends
converted to local form, or other text-mode
changes.

In URL: http://www.rpm.org/standards/RFC2440/
RFC 2440 section 5.9 Literal Data Packet (Tag 11)
says:
| 
| 5.9. Literal Data Packet (Tag 11)
| 
|    A Literal Data packet contains the body of a message; data that is
|    not to be further interpreted.
| 
|    The body of this packet consists of:
| 
|      - A one-octet field that describes how the data is formatted.
| 
|    If it is a 'b' (0x62), then the literal packet contains binary data.
|    If it is a 't' (0x74), then it contains text data, and thus may need
|    line ends converted to local form, or other text-mode changes.  RFC
|    1991 also defined a value of 'l' as a 'local' mode for machine-local
|    conversions.  This use is now deprecated.
| 
|      - File name as a string (one-octet length, followed by file name),
|        if the encrypted data should be saved as a file.
| 
|    If the special name "_CONSOLE" is used, the message is considered to
|    be "for your eyes only".  This advises that the message data is
|    unusually sensitive, and the receiving program should process it more
|    carefully, perhaps avoiding storing the received data to disk, for
|    example.
| 
|      - A four-octet number that indicates the modification date of the
|        file, or the creation time of the packet, or a zero that
|        indicates the present time.
| 
|      - The remainder of the packet is literal data.
| 
|    Text data is stored with <CR><LF> text endings (i.e. network-normal
|    line endings).  These should be converted to native line endings by
|    the receiving software.

Of course, if the GnuPG is reading in a text
message, but encoding in binary mode, it will
convert the native line endings into
network-normal line endings and the receiving
software will leave the text as-is.

> If many DOS mailers don't use the --textmode
> option to decrypt messages, we might be
> complained about that of LF, not CRLF,
> contrarily. I cannot verify this with DOS
> machines, sorry.

The receiving software is the one that does the
line ending transformation. It will already
have CRLF and not need any transformation
most of the time.

Fwiw: I also am unable to verify anything using
DOS machines. However, I have been using GnuPG to
send encrypted messages to a wide audience of
users (on all kinds of systems) for many years and
when I manually encrypted things before we had
added any hooks to use Gnus to do the pgg-gpg
magic, I always used --textmode for text messages.

Note: I have played with both method=pgpmime and
method=pgp and I have found that the largest
number of OpenPGP aware mail user agents being
used by the people that received my encrypted
and/or signed e-mail are able to handle method=pgp
more often than method=pgpmime.

That said, if I were using method=pgpmime and I
had an attachment that was a binary file, the
patch I provided would be a problem. There is no
way to tell PGP that the contents of one
content-type should be --textmode (the body of the
message) while the contents of the attachment
should be in --no-textmode (or defaulted to binary
mode). In binary mode, text lines are to be
canonicalized to use CRLF for purposes of
generating signatures.

The big problem here, is if I have multiple
attachments that also need to be encrypted and
some of those attachments are binary and some are
text. There is no easy way to express to MH-E or
Gnus that --textmode should only be used for
the lines in the text part of the message and
that the attachment must be treated as binary.

What I end up using is either separate PGP
encrypted components, or I do a base64 or uuencode
of my binary attachment prior to adding it
to my message to be sent.

So, it is clear that my patch is not good in the
general case, however, it is probably desirable to
have some way for MH-E to indicate that the
- --textmode should be used for the body of the
message and not used for an attachment.

I would be more than willing to help you test
any changes you might want to add to help make
this more configurable to Gnus.

	Thank you,
	-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFDzhKYCg7APGsDnFERAttbAJ4tJvNQLT3pzb/yHVSUsu9zja285ACgiWiq
evnPLiynu57Dc5W8vQYiiAc=
=L9Mc
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

>>>>> In <53032.1137578648@juniper.net> Mark D. Baushke wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> Doesn't the patch cause inconvenience to DOS users?

> It should work without any problems to DOS users.

> What is happening is that --textmode tells GnuPG to send a literal
> Data Packet (Tag 11) with a data format of 't' (0x74) to specify
> that the packet contains text data and thus may need line ends
> converted to local form, or other text-mode changes.

[...]

Thank you for the information.  I roughly understood that
`gpg --textmode' generates a *text* packet and recipients should
treat it as text because it is *text*.

[...]

> Note: I have played with both method=pgpmime and method=pgp and I
> have found that the largest number of OpenPGP aware mail user agents
> being used by the people that received my encrypted and/or signed
> e-mail are able to handle method=pgp more often than method=pgpmime.

> That said, if I were using method=pgpmime and I had an attachment
> that was a binary file, the patch I provided would be a
> problem. There is no way to tell PGP that the contents of one
> content-type should be --textmode (the body of the message) while
> the contents of the attachment should be in --no-textmode (or
> defaulted to binary mode). In binary mode, text lines are to be
> canonicalized to use CRLF for purposes of generating signatures.

> The big problem here, is if I have multiple attachments that also
> need to be encrypted and some of those attachments are binary and
> some are text. There is no easy way to express to MH-E or Gnus that
> --textmode should only be used for the lines in the text part of the
> message and that the attachment must be treated as binary.

I was also worried about things similar.  However, I noticed
pgg-gpg-encrypt-region uses pgg-as-lbt, which always add CRs to
line endings.  Perhaps it is not wrong that I consider it is
designed to handle only text.  Though, it might be data encoded
by base64, etc.  In fact, there seems to be no way to encrypt
binary data directly using Gnus and MML.  Could anyone correct
me?

I will install your patch if no one comments.

By the way, I found out the original author changed it not to
use --textmode over six years ago.

1999-11-05   Daiki Ueno  <>
[...]
	* pgg-gpg.el (encrypt-region): Don't use "--textmode" in GPG
	arguments, replace line break code with CRLF while signing
	instead.

This was done in SEMI before PGG was imported into Gnus.  But I
believe --textmode is needed there now.

> What I end up using is either separate PGP encrypted components, or
> I do a base64 or uuencode of my binary attachment prior to adding it
> to my message to be sent.

> So, it is clear that my patch is not good in the general case,
> however, it is probably desirable to have some way for MH-E to
> indicate that the --textmode should be used for the body of the
> message and not used for an attachment.

> I would be more than willing to help you test any changes you might
> want to add to help make this more configurable to Gnus.

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: multipart/mixed; boundary="=-=-=", Size: 7983 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --=-=-=

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> >>>>> In <53032.1137578648@juniper.net> Mark D. Baushke wrote:
> 
> > Katsumi Yamaoka <yamaoka@jpl.org> writes:
> 
> >> Doesn't the patch cause inconvenience to DOS users?
> 
> > It should work without any problems to DOS users.
> 
> > What is happening is that --textmode tells GnuPG to send a literal
> > Data Packet (Tag 11) with a data format of 't' (0x74) to specify
> > that the packet contains text data and thus may need line ends
> > converted to local form, or other text-mode changes.
> 
> [...]
> 
> Thank you for the information.  I roughly understood that
> `gpg --textmode' generates a *text* packet and recipients should
> treat it as text because it is *text*.
> 
> [...]

Ahh... Rereading my message in the light of day, it seems I was a bit
more tired than I thought. Sorry for the rambling explaination...

> I will install your patch if no one comments.

Thank you.

> By the way, I found out the original author changed it not to
> use --textmode over six years ago.
> 
> 1999-11-05   Daiki Ueno  <>
> [...]
> 	* pgg-gpg.el (encrypt-region): Don't use "--textmode" in GPG
> 	arguments, replace line break code with CRLF while signing
> 	instead.
> 
> This was done in SEMI before PGG was imported into Gnus.  But I
> believe --textmode is needed there now.

Okay.

Oh, by the way, I received an e-mail today where the Mutt pgp-signed
message comes out like this:

To: mdb@juniper.net
From: "Mark D. Baushke" <mdb@gnu.org>
Subject: another pgp test
Date: Wed, 18 Jan 2006 09:12:29 -0800


[[PGP Signed Part:Undecided]]

[1. application/pgp]...

[[End of PGP Signed Part]]

or

[[PGP Signed Part:Mark D Baushke <mdb@gnu.org>]]

[1. application/pgp]...

[[End of PGP Signed Part]]

when I explicitly run mh-show-inline-mime-part on the message part,
then the body of the message is readable under the

  [1. application/pgp]...

text. I will include a copy of a similar message that illustrates the
problem. I am not sure why the behavior difference should exist.

	-- Mark


- --=-=-=
Content-Type: text/x-mail
Content-Disposition: attachment; filename=4
Content-Description: Test case 4. A signed forwarded message.

To: mdb@juniper.net
From: "Mark D. Baushke" <mdb@gnu.org>
Subject: another pgp test
Content-Type: application/pgp; x-action=sign; format=text
Content-Disposition: inline; filename="msg.pgp"
MIME-Version: 1.0
Date: Wed, 18 Jan 2006 09:12:29 -0800
Message-ID: <70397.1137604349@juniper.net>

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is an example of a forwarded message.

- - - Mark

- - ----- Forwarded message from FreeBSD Security Advisories <security-advisories@freebsd.org> -----

X-Original-To: freebsd-security-notifications@freebsd.org
Delivered-To: freebsd-security-notifications@freebsd.org
Date: Wed, 18 Jan 2006 09:10:16 GMT
X-Authentication-Warning: freefall.freebsd.org: cperciva set sender to
	security-advisories@freebsd.org using -f
From: FreeBSD Security Advisories <security-advisories@freebsd.org>
To: FreeBSD Security Advisories <security-advisories@freebsd.org>
Precedence: bulk
Cc: 
Subject: FreeBSD Security Advisory FreeBSD-SA-06:05.80211
X-BeenThere: freebsd-security-notifications@freebsd.org
X-Mailman-Version: 2.1.5
Reply-To: security-advisories@freebsd.org
List-Id: "Moderated Security Notifications \[moderated,
	low volume\]" <freebsd-security-notifications.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications>,
	<mailto:freebsd-security-notifications-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security-notifications>
List-Post: <mailto:freebsd-security-notifications@freebsd.org>
List-Help: <mailto:freebsd-security-notifications-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications>,
	<mailto:freebsd-security-notifications-request@freebsd.org?subject=subscribe>
Errors-To: owner-freebsd-security-notifications@freebsd.org
X-Not-Spam: Spam Score: 1.804 - ADDR_FREE
X-Scanned-By: MIMEDefang 2.39

=============================================================================
FreeBSD-SA-06:05.80211                                      Security Advisory
                                                          The FreeBSD Project

Topic:          IEEE 802.11 buffer overflow

Category:       core
Module:         net80211
Announced:      2006-01-18
Credits:        Karl Janmar
Affects:        FreeBSD 6.0
Corrected:      2006-01-18 09:03:15 UTC (RELENG_6, 6.0-STABLE)
                2006-01-18 09:03:36 UTC (RELENG_6_0, 6.0-RELEASE-p3)
CVE Name:       CVE-2006-0226

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
<URL:http://www.freebsd.org/security/>.

I.   Background

The IEEE 802.11 network subsystem of FreeBSD implements the protocol
negotiation used for wireless networking.

II.  Problem Description

An integer overflow in the handling of corrupt IEEE 802.11 beacon or
probe response frames when scanning for existing wireless networks can
result in the frame overflowing a buffer.

III. Impact

An attacker able broadcast a carefully crafted beacon or probe response
frame may be able to execute arbitrary code within the context of the
FreeBSD kernel on any system scanning for wireless networks.

IV.  Workaround

No workaround is available, but systems without IEEE 802.11 hardware or
drivers loaded are not vulnerable.

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to 6-STABLE or to the RELENG_6_0
security branch dated after the correction date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 6.0 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-06:05/80211.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-06:05/80211.patch.asc

b) Apply the patch.

# cd /usr/src
# patch < /path/to/patch

c) Recompile your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html> and reboot the
system.

VI.  Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

Branch                                                           Revision
  Path
- - - -------------------------------------------------------------------------
RELENG_6
  src/sys/net80211/ieee80211_ioctl.c                             1.25.2.9
RELENG_6_0
  src/UPDATING                                              1.416.2.3.2.8
  src/sys/conf/newvers.sh                                    1.69.2.8.2.4
  src/sys/net80211/ieee80211_ioctl.c                         1.25.2.3.2.1
- - - -------------------------------------------------------------------------

VII. References

http://www.signedness.org/advisories/sps-0x1.txt
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0226

The latest revision of this advisory is available at
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-06:05.80211.asc
_______________________________________________
freebsd-security-notifications@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications
To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe@freebsd.org"

- - ----- End forwarded message -----
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFDznb9Cg7APGsDnFERAja0AKC5obSkiWNH+ARuug7m+16WwiwUrQCgitir
8UAT7d2NTCf3P0IlwYaUJjI=
=H3rq
- -----END PGP SIGNATURE-----

- --=-=-=--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFDznnuCg7APGsDnFERAr1tAJ4n1LwhzMiGhJAVVySheLHcS+bYGACeOb9k
Lty+jAp+sUyB4YFCxMRmG0o=
=uP/Z
-----END PGP SIGNATURE-----

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

Hi Katsumi,

Hmmm... my last message tried to sign an attachment with the wrong mode,
and odd things happened to it...

I'll just attach test case 4 without signing this message...

	-- Mark


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: test case 4 - a signed forwarded message --]
[-- Type: text/x-mail, Size: 5527 bytes --]

To: mdb@juniper.net
From: "Mark D. Baushke" <mdb@gnu.org>
Subject: another pgp test
Content-Type: application/pgp; x-action=sign; format=text
Content-Disposition: inline; filename="msg.pgp"
MIME-Version: 1.0
Date: Wed, 18 Jan 2006 09:12:29 -0800
Message-ID: <70397.1137604349@juniper.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is an example of a forwarded message.

- - Mark

- ----- Forwarded message from FreeBSD Security Advisories <security-advisories@freebsd.org> -----

X-Original-To: freebsd-security-notifications@freebsd.org
Delivered-To: freebsd-security-notifications@freebsd.org
Date: Wed, 18 Jan 2006 09:10:16 GMT
X-Authentication-Warning: freefall.freebsd.org: cperciva set sender to
	security-advisories@freebsd.org using -f
From: FreeBSD Security Advisories <security-advisories@freebsd.org>
To: FreeBSD Security Advisories <security-advisories@freebsd.org>
Precedence: bulk
Cc: 
Subject: FreeBSD Security Advisory FreeBSD-SA-06:05.80211
X-BeenThere: freebsd-security-notifications@freebsd.org
X-Mailman-Version: 2.1.5
Reply-To: security-advisories@freebsd.org
List-Id: "Moderated Security Notifications \[moderated,
	low volume\]" <freebsd-security-notifications.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications>,
	<mailto:freebsd-security-notifications-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security-notifications>
List-Post: <mailto:freebsd-security-notifications@freebsd.org>
List-Help: <mailto:freebsd-security-notifications-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications>,
	<mailto:freebsd-security-notifications-request@freebsd.org?subject=subscribe>
Errors-To: owner-freebsd-security-notifications@freebsd.org
X-Not-Spam: Spam Score: 1.804 - ADDR_FREE
X-Scanned-By: MIMEDefang 2.39

=============================================================================
FreeBSD-SA-06:05.80211                                      Security Advisory
                                                          The FreeBSD Project

Topic:          IEEE 802.11 buffer overflow

Category:       core
Module:         net80211
Announced:      2006-01-18
Credits:        Karl Janmar
Affects:        FreeBSD 6.0
Corrected:      2006-01-18 09:03:15 UTC (RELENG_6, 6.0-STABLE)
                2006-01-18 09:03:36 UTC (RELENG_6_0, 6.0-RELEASE-p3)
CVE Name:       CVE-2006-0226

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
<URL:http://www.freebsd.org/security/>.

I.   Background

The IEEE 802.11 network subsystem of FreeBSD implements the protocol
negotiation used for wireless networking.

II.  Problem Description

An integer overflow in the handling of corrupt IEEE 802.11 beacon or
probe response frames when scanning for existing wireless networks can
result in the frame overflowing a buffer.

III. Impact

An attacker able broadcast a carefully crafted beacon or probe response
frame may be able to execute arbitrary code within the context of the
FreeBSD kernel on any system scanning for wireless networks.

IV.  Workaround

No workaround is available, but systems without IEEE 802.11 hardware or
drivers loaded are not vulnerable.

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to 6-STABLE or to the RELENG_6_0
security branch dated after the correction date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 6.0 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-06:05/80211.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-06:05/80211.patch.asc

b) Apply the patch.

# cd /usr/src
# patch < /path/to/patch

c) Recompile your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html> and reboot the
system.

VI.  Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

Branch                                                           Revision
  Path
- - -------------------------------------------------------------------------
RELENG_6
  src/sys/net80211/ieee80211_ioctl.c                             1.25.2.9
RELENG_6_0
  src/UPDATING                                              1.416.2.3.2.8
  src/sys/conf/newvers.sh                                    1.69.2.8.2.4
  src/sys/net80211/ieee80211_ioctl.c                         1.25.2.3.2.1
- - -------------------------------------------------------------------------

VII. References

http://www.signedness.org/advisories/sps-0x1.txt
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0226

The latest revision of this advisory is available at
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-06:05.80211.asc
_______________________________________________
freebsd-security-notifications@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications
To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe@freebsd.org"

- ----- End forwarded message -----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFDznb9Cg7APGsDnFERAja0AKC5obSkiWNH+ARuug7m+16WwiwUrQCgitir
8UAT7d2NTCf3P0IlwYaUJjI=
=H3rq
-----END PGP SIGNATURE-----

Synch of PGG (was Re: Gnus 5.10.6 problems with PGP/MIME (test cases))

[Katsumi Yamaoka]

>>>>> In <75578.1137605102@juniper.net> Mark D. Baushke wrote:

>> I will install your patch if no one comments.

> Thank you.

I've applied the --textmode patch to the Gnus CVS trunk.
However, oops, it has already been added to the v5-10 branch
(i.e., Gnus 5.10.7).  Besides this, some changes not synch'd
with the trunk have been made in the v5-10 branch.  Is there any
reason we don't merge them into the trunk?  Here they are:

2005-11-04 Ken Manheimer  <ken.manheimer@gmail.com>

	* pgg-pgp.el (pgg-pgp-encrypt-region, pgg-pgp-decrypt-region)
	(pgg-pgp-encrypt-symmetric-region, pgg-pgp-encrypt-symmetric)
	(pgg-pgp-encrypt, pgg-pgp-decrypt-region, pgg-pgp-decrypt)
	(pgg-pgp-sign-region, pgg-pgp-sign): Add optional 'passphrase'
	argument to all these routines, so the passphrase can be managed
	externally and passed in to the system.
	(pgg-pgp-decrypt-region, pgg-pgp-sign-region): Use new name for
	pgg-add-passphrase-to-cache function.

	* pgg-pgp5.el (pgg-pgp5-encrypt-region, pgg-pgp5-decrypt-region)
	(pgg-pgp5-encrypt-symmetric-region, pgg-pgp5-encrypt-symmetric)
	(pgg-pgp5-encrypt, pgg-pgp5-decrypt-region, pgg-pgp5-decrypt)
	(pgg-pgp5-sign-region, pgg-pgp5-sign): Add optional 'passphrase'
	argument to all these routines, so the passphrase can be managed
	externally and passed in to the system.
	(pgg-pgp5-sign-region): Use new name of	pgg-add-passphrase-to-cache
	function.

2005-10-29  Ken Manheimer  <ken.manheimer@gmail.com>

	* pgg-gpg.el (pgg-gpg-select-matching-key): Fix: look at the right
	part of the decoded armor to find the key-identifier.
	(pgg-gpg-lookup-key-owner): New function to return the
	human-readable identifier of a key owner.
	(pgg-gpg-lookup-id-from-key-owner): Make it easy to identify the
	key itself.
	(pgg-gpg-decrypt-region): Prompt with the key owner (rather than
	the key value) if we have a key and can match it against a secret
	key.  Also, added a note pointing out fact that the prompt only
	indicates the first matching key.

	* pgg.el (pgg-decrypt): Passing along 'passphrase' in call to
	pgg-decrypt-region.
	(pgg-pending-timers): A new hash for tracking the passphrase cache
	timers, so that new ones supercede old ones.
	(pgg-add-passphrase-to-cache): Rename from
	`pgg-add-passphrase-cache' to reduce confusion (all callers
	changed).  Modified to cancel old timers when new ones are added.
	(pgg-remove-passphrase-from-cache): Rename from
	`pgg-remove-passphrase-cache' to reduce confusion (all callers
	changed).  Modified to cancel old timers when their keys are
	removed from the cache.
	(pgg-cancel-timer): In Emacs, an alias for cancel-timer; in
	XEmacs, an indirection to delete-itimer.
	(pgg-read-passphrase-from-cache, pgg-read-passphrase):
	Extract pgg-read-passphrase-from-cache from pgg-read-passphrase so
	users can only check cache without risk of prompting.  Correct bug in
	notruncate behavior.
	(pgg-read-passphrase-from-cache, pgg-read-passphrase)
	(pgg-add-passphrase-cache, pgg-remove-passphrase-cache):
	Add informative docstrings.
	(pgg-decrypt): Convey provided passphrase in subordinate call to
	pgg-decrypt-region.

2005-10-20  Ken Manheimer <ken.manheimer+emacs@gmail.com>

	* pgg.el (pgg-encrypt-region, pgg-encrypt-symmetric-region)
	(pgg-encrypt-symmetric, pgg-encrypt, pgg-decrypt-region)
	(pgg-decrypt, pgg-sign-region, pgg-sign): Add optional
	'passphrase' argument, so the passphrase can be managed externally
	and then passed in to the system.

	* pgg.el (pgg-read-passphrase, pgg-add-passphrase-cache)
	(pgg-remove-passphrase-cache): Add optional 'notruncate' argument,
	so the passphrase cache can be used reliably with identifiers
	besides a pgp packet's key id.

	* pgg-gpg.el (pgg-pgp-encrypt-region)
	(pgg-pgp-encrypt-symmetric-region, pgg-pgp-encrypt-symmetric)
	(pgg-pgp-encrypt, pgg-pgp-decrypt-region, pgg-pgp-decrypt)
	(pgg-pgp-sign-region, pgg-pgp-sign): Add optional 'passphrase'
	argument to all these routines, so the passphrase can be managed
	externally and passed in to the system.

	* pgg-gpg.el (pgg-gpg-possibly-cache-passphrase): Add optional
	'notruncate' argument, so the passphrase cache can be used
	reliably with identifiers besides a pgp packet's key id.

2005-10-29  Sascha Wilde  <swilde@sha-bang.de>

	* pgg-gpg.el (pgg-gpg-encrypt-symmetric-region): New function for
	symmetric encryption.
	(pgg-gpg-symmetric-key-p): New function to check for an symmetric
	encrypted session key.
	(pgg-gpg-decrypt-region): When decrypting a symmetric encrypted
	message ask for the passphrase in a proper way.

	* pgg.el (pgg-encrypt-symmetric, pgg-encrypt-symmetric-region):
	New user commands for symmetric encryption.

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

>>>>> In <75740.1137605353@juniper.net> Mark D. Baushke wrote:

> Hmmm... my last message tried to sign an attachment with the wrong mode,
> and odd things happened to it...

> I'll just attach test case 4 without signing this message...

I've fixed some codes in Gnus CVS.  Here's a patch for Gnus
5.10.6 following to those of <b4m4q45f1kf.fsf@jpl.org> and
<b4mirsjjfc1.fsf@jpl.org>:


[-- Attachment #2: gnus-5.10.6.diff-3.gz --]
[-- Type: application/x-gzip, Size: 549 bytes --]

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> >>>>> In <75740.1137605353@juniper.net> Mark D. Baushke wrote:
> 
> > Hmmm... my last message tried to sign an attachment with the wrong mode,
> > and odd things happened to it...
> 
> > I'll just attach test case 4 without signing this message...
> 
> I've fixed some codes in Gnus CVS.  Here's a patch for Gnus
> 5.10.6 following to those of <b4m4q45f1kf.fsf@jpl.org> and
> <b4mirsjjfc1.fsf@jpl.org>:

This patch works for me.

	Thank you!
	-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFDz1hQCg7APGsDnFERAuwMAJ9XHFOBFb1TU6IcCG6iORUe3g8bPACgnt8l
reO1Pn8gLPlVcifjVxcAsAE=
=t0u/
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Synch of PGG

[Katsumi Yamaoka]

>>>>> In <b4m3bjkpxgx.fsf_-_@jpl.org> Katsumi Yamaoka wrote:

> I've applied the --textmode patch to the Gnus CVS trunk.
> However, oops, it has already been added to the v5-10 branch
> (i.e., Gnus 5.10.7).  Besides this, some changes not synch'd
> with the trunk have been made in the v5-10 branch.  Is there any
> reason we don't merge them into the trunk?

There cannot be a problem, I think.  I've merged those changes,
except for the programs caching passphrase, into the trunk just
now.

> Here they are:

> 2005-11-04 Ken Manheimer  <ken.manheimer@gmail.com>

[...]

> 2005-10-29  Ken Manheimer  <ken.manheimer@gmail.com>

[...]

> 2005-10-20  Ken Manheimer <ken.manheimer+emacs@gmail.com>

[...]

> 2005-10-29  Sascha Wilde  <swilde@sha-bang.de>

[...]

Re: Synch of PGG

[Simon Josefsson]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

>>>>>> In <b4m3bjkpxgx.fsf_-_@jpl.org> Katsumi Yamaoka wrote:
>
>> I've applied the --textmode patch to the Gnus CVS trunk.
>> However, oops, it has already been added to the v5-10 branch
>> (i.e., Gnus 5.10.7).  Besides this, some changes not synch'd
>> with the trunk have been made in the v5-10 branch.  Is there any
>> reason we don't merge them into the trunk?
>
> There cannot be a problem, I think.  I've merged those changes,
> except for the programs caching passphrase, into the trunk just
> now.

Thanks!  I have been meaning to do this for a while, but never found
time.  I agree that it is the right thing to do.

>> Here they are:
>
>> 2005-11-04 Ken Manheimer  <ken.manheimer@gmail.com>
>
> [...]
>
>> 2005-10-29  Ken Manheimer  <ken.manheimer@gmail.com>
>
> [...]
>
>> 2005-10-20  Ken Manheimer <ken.manheimer+emacs@gmail.com>
>
> [...]
>
>> 2005-10-29  Sascha Wilde  <swilde@sha-bang.de>
>
> [...]

Re: Synch of PGG

[Reiner Steib]

On Thu, Jan 19 2006, Katsumi Yamaoka wrote:

>>>>>> In <b4m3bjkpxgx.fsf_-_@jpl.org> Katsumi Yamaoka wrote:
>
>> I've applied the --textmode patch to the Gnus CVS trunk.
>> However, oops, it has already been added to the v5-10 branch
>> (i.e., Gnus 5.10.7).  Besides this, some changes not synch'd
>> with the trunk have been made in the v5-10 branch.  Is there any
>> reason we don't merge them into the trunk?
>
> There cannot be a problem, I think.  I've merged those changes,

Miles, is there a reason why you didn't sync those changes (coming
from Emacs CVS) to the Gnus trunk?  Or was it just an oversight?

> except for the programs caching passphrase, into the trunk just now.

If possible, all changes should go to the trunk as well.  Isn't this
possible for these changes?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Synch of PGG

[Miles Bader]

2006/1/19, Reiner Steib <reinersteib+gmane@imap.cc>:
> > There cannot be a problem, I think.  I've merged those changes,
>
> Miles, is there a reason why you didn't sync those changes (coming
> from Emacs CVS) to the Gnus trunk?  Or was it just an oversight?

Er, well actually the reason was that pgg was all screwed up (at least
at the time, the 5.10 and  gnus trunk versions of pgg seemed to have
diverged to the point where merging was a real puzzle).  I eventually
gave up trying to merge it, and planned to try to find a pgg person to
do it, but maybe Katsumi has done it?

I'll give another shot at merging 5.10 into the trunk...

BTW, if anyone's interested in arch, my arch branches of gnus are now
hosted on savannah, so theoretically, any gnus hacker that has emacs
write privs on savannah can directly commit to the arch branches
there...

Thanks,

-Miles
--
Do not taunt Happy Fun Ball.

Re: Synch of PGG

[Katsumi Yamaoka]

>>>>> In <v9zmlsbamy.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Thu, Jan 19 2006, Katsumi Yamaoka wrote:

>> except for the programs caching passphrase,

> If possible, all changes should go to the trunk as well.  Isn't this
> possible for these changes?

Since those things in the v5-10 branch looked substitutes for
password.el to me, I didn't merge them into the trunk.

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Daiki Ueno]

>>>>> In <b4mpsmp3e11.fsf@jpl.org> 
>>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> Thank you for the information.  I roughly understood that
> `gpg --textmode' generates a *text* packet and recipients should
> treat it as text because it is *text*.

Though I have not yet read entire discussion, you are talking about
non-MIME encryption?  If so, it might be preferable that --textmode is
specified only in that case.

If --textmode is specified, gpg _itself_ converts line ending.

On the GNU/Linux system:

$ ruby -e 'puts("abc\r\ndef\r\nghi\r\n")' > test.txt
$ gpg -q --encrypt --textmode -r ueno@unixuser.org test.txt
$ gpg -q --decrypt test.txt.gpg > test.txt
You need a passphrase to unlock the secret key for
user: "Daiki Ueno <ueno@unixuser.org>"
...
$ hd test.txt
00000000  61 62 63 0a 64 65 66 0a  67 68 69 0a              |abc.def.ghi.|
0000000c

All CRLF are converted to LF.  This might cause a problem if you send an
encrypted and signed data in RFC1847 encapsulation (RFC3156, section
6.1).  After decryption, it does no longer contain the signed material
identical as before encryption.

> I will install your patch if no one comments.

Please add *me* to the Cc: list if you mention changes obviously
conflicting with my intension such as below.  Otherwise, I will not be
aware of them.

> By the way, I found out the original author changed it not to
> use --textmode over six years ago.

> 1999-11-05   Daiki Ueno  <>
> [...]
> 	* pgg-gpg.el (encrypt-region): Don't use "--textmode" in GPG
> 	arguments, replace line break code with CRLF while signing
> 	instead.

Regards,
-- 
Daiki Ueno

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Daiki,

Daiki Ueno <ueno@unixuser.org> writes:

> >>>>> In <b4mpsmp3e11.fsf@jpl.org> 
> >>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> > Thank you for the information.  I roughly understood that
> > `gpg --textmode' generates a *text* packet and recipients should
> > treat it as text because it is *text*.
> 
> Though I have not yet read entire discussion, you are talking about
> non-MIME encryption?

Well, the majority of the thread was dealing with various MIME markers
and recognition of PGP encrypted or signed messages. These problems have
involved fixes to the files: gnus-art.el, mm-uu.el, mm-decode.el,
mm-bodies.el:

		------- start ChangeLog entries -------
2006-01-19  Katsumi Yamaoka  <yamaoka@jpl.org>

	* mm-bodies.el (mm-decode-body): Don't decode decoded body.

	* mm-uu.el (mm-uu-dissect-text-parts): Dissect dissected parts.

2006-01-17  Katsumi Yamaoka  <yamaoka@jpl.org>

	* mm-decode.el (mm-inlined-types): Add application/pgp.
	(mm-automatic-display): Ditto.

	* mm-uu.el (mm-uu-dissect-text-parts): Recognize application/pgp
	part as text.

2004-10-06  Katsumi Yamaoka  <yamaoka@jpl.org>

	* mm-uu.el (mm-uu-dissect): Allow optional arg.
	(mm-uu-dissect-text-parts): New function.

	* gnus-art.el (gnus-display-mime): Use mm-uu-dissect-text-parts to
	dissect text parts.

		 ------- end ChangeLog entries -------

Starting with Message-ID: <85906.1137521874@juniper.net> on 2006-01-17,
I brought up a problem I had obseved with both non-MIME PGP (method=pgp)
as well as PGP/MIME (method=pgpmime) which BOTH go through the
pgg-gpg-encrypt-region function. At the end of this process, messages
that being decrypted by non-GNUS mail user agents were seeing CRLF in
the decrypted message files where they expected to see local line ending
conventions being used.

> If so, it might be preferable that --textmode is specified only in
> that case.

Well, I do not understand the pgg-gpg-encrypt-region code well enough to
suggest how one could add such a customization at present.

> If --textmode is specified, gpg _itself_ converts line ending.

Yes, this matches my understanding. The input is considered to be
text and on a GNU/Linux system, this means that CR characters will
be purged and LF will be converted to CRLF. At the remote end, the
CRLF will be converted into the local line ending style which may
or may not be CRLF. If the system is another GNU/Linux system, you
will have lost any CR characters from the file.

> On the GNU/Linux system:
> 
> $ ruby -e 'puts("abc\r\ndef\r\nghi\r\n")' > test.txt
> $ gpg -q --encrypt --textmode -r ueno@unixuser.org test.txt
> $ gpg -q --decrypt test.txt.gpg > test.txt
> You need a passphrase to unlock the secret key for
> user: "Daiki Ueno <ueno@unixuser.org>"
> ...
> $ hd test.txt
> 00000000  61 62 63 0a 64 65 66 0a  67 68 69 0a              |abc.def.ghi.|
> 0000000c

Yes, this appears to be correct. It is also correct that if you had a
MacOS 9 text file 

$ ruby -e 'puts("abc\rdef\rghi\r")' > test2.txt
$ gpg -q --encrypt --textmode -r ueno@unixuser.org test.txt
$ mv test2.txt  test2.txt.orig

$ gpg -q --decrypt test.txt.gpg > test.txt
You need a passphrase to unlock the secret key for
user: "Daiki Ueno <ueno@unixuser.org>"
...
$ od -x test2.txt.orig; od -x test2.txt
0000000 6261 0d63 6564 0d66 6867 0d69
0000014
0000000 6261 6463 6665 6867 0069
0000011
$ 

As you can see, the CR is removed. As there was no LF in this test case,
the file does not have a trailing LF added to the file.

> All CRLF are converted to LF.  This might cause a problem if you send an
> encrypted and signed data in RFC1847 encapsulation (RFC3156, section
> 6.1).  After decryption, it does no longer contain the signed material
> identical as before encryption.

You are correct.

I did raise this as a potential problem in Message-ID:
<53032.1137578648@juniper.net> on 2006-01-18:

I wrote:

| That said, if I were using method=pgpmime and I
| had an attachment that was a binary file, the
| patch I provided would be a problem. There is no
| way to tell PGP that the contents of one
| content-type should be --textmode (the body of the
| message) while the contents of the attachment
| should be in --no-textmode (or defaulted to binary
| mode). In binary mode, text lines are to be
| canonicalized to use CRLF for purposes of
| generating signatures.
| 
| The big problem here, is if I have multiple
| attachments that also need to be encrypted and
| some of those attachments are binary and some are
| text. There is no easy way to express to MH-E or
| Gnus that --textmode should only be used for
| the lines in the text part of the message and
| that the attachment must be treated as binary.
| 
| What I end up using is either separate PGP
| encrypted components, or I do a base64 or uuencode
| of my binary attachment prior to adding it
| to my message to be sent.
| 
| So, it is clear that my patch is not good in the
| general case, however, it is probably desirable to
| have some way for MH-E to indicate that the
| --textmode should be used for the body of the
| message and not used for an attachment.
| 
| I would be more than willing to help you test
| any changes you might want to add to help make
| this more configurable to Gnus.

> > I will install your patch if no one comments.
> 
> Please add *me* to the Cc: list if you mention changes obviously
> conflicting with my intension such as below.  Otherwise, I will not be
> aware of them.

FYI. I believe that Katsumi has already modified CVS GNUS with my patch:

		 ------- start ChangeLog entry -------
|2006-01-19  Mark D. Baushke  <mdb@gnu.org>
|
|	* pgg-gpg.el (pgg-gpg-encrypt-region): Add --textmode to gpg args.
		  ------- end ChangeLog entry -------

However, as I have said previously, I would be very willing to use some
other method if there were a more flexible way in the system to
optionally have the --textmode switch added or not as appropriate to the
MIME type.

> > By the way, I found out the original author changed it not to
> > use --textmode over six years ago.
> 
> > 1999-11-05   Daiki Ueno  <>
> > [...]
> > 	* pgg-gpg.el (encrypt-region): Don't use "--textmode" in GPG
> > 	arguments, replace line break code with CRLF while signing
> > 	instead.
> 
> Regards,
> -- 
> Daiki Ueno

	Thanks,
	-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFD6EhWCg7APGsDnFERArKeAJ9KUIzUsUlI5oDFOxNBoFT9m43F/gCg9hzV
fh/Kdbxj83I7I1tPKmcgL60=
=CSlG
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

>>>>> In <b258afad-11cd-4abc-99ba-89c99615ef53@well-done.deisui.org>
>>>>>	Daiki Ueno wrote:

>>>>>> In <b4mpsmp3e11.fsf@jpl.org>
>>>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:

>> Thank you for the information.  I roughly understood that
>> `gpg --textmode' generates a *text* packet and recipients should
>> treat it as text because it is *text*.

> Though I have not yet read entire discussion, you are talking about
> non-MIME encryption?

No, I thought that it includes not only non-MIME encryption but
also MIME encryption.

> If so, it might be preferable that --textmode is specified only in
> that case.  If --textmode is specified, gpg _itself_ converts line
> ending.

`pgg-gpg-encrypt-region' always inserts CR in every line ending
of text using `(pgg-as-lbt START END 'CRLF BODY)'.  So, if the
--textmode option is not specified, gpg doesn't treat sending
data as text and recipients will see ^Ms in a decrypted message.

However, only recipients who use Gnus will never see ^Ms because
`pgg-gpg-process-region' uses `raw-text-dos' when reading a
decrypted message from a temp file, and furthermore,
`mml2015-pgg-decrypt' converts CRLF to LF.

> On the GNU/Linux system:

> $ ruby -e 'puts("abc\r\ndef\r\nghi\r\n")' > test.txt
> $ gpg -q --encrypt --textmode -r ueno@unixuser.org test.txt
> $ gpg -q --decrypt test.txt.gpg > test.txt
> You need a passphrase to unlock the secret key for
> user: "Daiki Ueno <ueno@unixuser.org>"
> ...
> $ hd test.txt
> 00000000  61 62 63 0a 64 65 66 0a  67 68 69 0a              |abc.def.ghi.|
> 0000000c

> All CRLF are converted to LF.

Yes, that's right.

> This might cause a problem if you send an
> encrypted and signed data in RFC1847 encapsulation (RFC3156, section
> 6.1).  After decryption, it does no longer contain the signed material
> identical as before encryption.

That's indeed a problem.  Do you know the way to verify it using
Gnus?  I don't know what mml command do that.  In addition, do
you have an idea to solve the ^Ms problem that I mentioned above?

> Please add *me* to the Cc: list if you mention changes obviously
> conflicting with my intension such as below.  Otherwise, I will not be
> aware of them.

I'm sorry to have not informed it to you.  I must do it from the
next time.  I thought informing it to you was not necessary
because I found out someone added --textmode in Gnus of the
Emacs version (i.e., Gnus v5.11) before I did it.  I couldn't
discover who did it in Emacs when, though.

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Daiki Ueno]

Thanks Mark for summarizing the discussion.

>>>>> In <b4mek2fa9wu.fsf@jpl.org> 
>>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> `pgg-gpg-encrypt-region' always inserts CR in every line ending
> of text using `(pgg-as-lbt START END 'CRLF BODY)'.  So, if the
> --textmode option is not specified, gpg doesn't treat sending
> data as text and recipients will see ^Ms in a decrypted message.

> In addition, do you have an idea to solve the ^Ms problem that I
> mentioned above?

Is it not enough that we simply omit pgg-as-lbt from
pgg-gpg-encrypt-region?

For MIME encryption, it is MUA (not PGP libraries) that should be
responsible for converting LF to CRLF in encrypted messages since MIME
encryption is only applicable to messages in MIME canonical format.

For non-MIME encryption, line-ending conversion is not needed at all.

Regards,
-- 
Daiki Ueno

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daiki Ueno <ueno@unixuser.org> writes:

> Thanks Mark for summarizing the discussion.

You are welcome.

> >>>>> In <b4mek2fa9wu.fsf@jpl.org> 
> >>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> > `pgg-gpg-encrypt-region' always inserts CR in every line ending
> > of text using `(pgg-as-lbt START END 'CRLF BODY)'.  So, if the
> > --textmode option is not specified, gpg doesn't treat sending
> > data as text and recipients will see ^Ms in a decrypted message.
> 
> > In addition, do you have an idea to solve the ^Ms problem that I
> > mentioned above?
> 
> Is it not enough that we simply omit pgg-as-lbt from
> pgg-gpg-encrypt-region?
> 
> For MIME encryption, it is MUA (not PGP libraries) that should be
> responsible for converting LF to CRLF in encrypted messages since MIME
> encryption is only applicable to messages in MIME canonical format.

Could you please provide the RFC reference for this?

I see in RFC 2015 where it talks about CRLF being canonical for
signatures validation, but it also says that the MUA needs to convert
line endings to the canonical <CR><LF> sequence before the signature can
be verified. This is necessary since the local MTA may ahe converted to
a local end of line convention.

However, I do NOT see it specify that arbitrary data which is being
encrypted should have conversions forced on it at all.

If it is text, then there is a packet type specified in RFC 2440
which specifies the <CR><LF> as the canonical format and a marker that
the packet is text (this is what the --textmode switch to gpg does).

> For non-MIME encryption, line-ending conversion is not needed at all.

I disagree. This is what started the debate in the first place.

If I am sending a text message, then changing the line endings to CRLF
as is done in pgg-gpg-encrypt-region should also tell the remote end
that a text packet is coming rather than arbitrary binary data.

This is also true if I am on a CRLF line ending system and sending an
encrypted text message to a LF line ending system.

I contend that the Gnus system should know if the user is encrypted an
attachment or normal text and tell the underlying transport to do the
right thing so that all permutations of line endings (CR, CRLF, LF,
line-oriented byte count) on each end of the system will know what to
do with the encrypted data.

	Thanks,
	-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFD6Gr0Cg7APGsDnFERAq3cAKCORDhuF1d3IfXA9lvQJt3GK4BjQQCguS/B
bVtmekIA4N7BS8dTh4c92TI=
=v/pF
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

>>>>> In <8b63142a-b090-4783-a3a5-0832d7289f38@well-done.deisui.org> Daiki Ueno wrote:

>> In addition, do you have an idea to solve the ^Ms problem that I
>> mentioned above?

> Is it not enough that we simply omit pgg-as-lbt from
> pgg-gpg-encrypt-region?

Well, doesn't it mean a decrypted message appears with LF, not
CRLF in DOS recipients?  In other words, do DOS recipients have
a means to detect whether a message is text, not binary data,
without specifying --textmode by a sender?  Gnus doesn't seem to
say it is text in MIME headers, etc.  I'm not sure of it since
I'm not familiar with DOS unfortunately.

> For MIME encryption, it is MUA (not PGP libraries) that should be
> responsible for converting LF to CRLF in encrypted messages since MIME
> encryption is only applicable to messages in MIME canonical format.

I agree all MUAs should do it, though I'm not sure whether all
of them do so.

> For non-MIME encryption, line-ending conversion is not needed at all.

Hm, I need to consider it further.  Probably I don't have enough
understanding of gpg.

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Daiki Ueno]

>>>>> In <b4mbqxjjxlx.fsf@jpl.org> 
>>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> >>>>> In <8b63142a-b090-4783-a3a5-0832d7289f38@well-done.deisui.org> Daiki Ueno wrote:

> >> In addition, do you have an idea to solve the ^Ms problem that I
> >> mentioned above?

> > Is it not enough that we simply omit pgg-as-lbt from
> > pgg-gpg-encrypt-region?

> > For MIME encryption, it is MUA (not PGP libraries) that should be
> > responsible for converting LF to CRLF in encrypted messages since MIME
> > encryption is only applicable to messages in MIME canonical format.

> I agree all MUAs should do it, though I'm not sure whether all
> of them do so.

> > For non-MIME encryption, line-ending conversion is not needed at all.

> Hm, I need to consider it further.  Probably I don't have enough
> understanding of gpg.

I suspect you are confused with the distinction between the MUA (Gnus)
and the PGP library (PGG).  PGG provides a general facility to use PGP
commands from Emacs and is now used by a program other than Gnus.

What I suggested was to make all input to pgg-encrypt-region (for
PGP/MIME encryption) MIME canonical format with CRLF line-endings by
Gnus and remove line-end conversion code from PGG.

BTW, would you please revert the the --textmode patch until the real
problem is clear to us?

FYI, I found that two major MUA (Mozilla Thunderbird with Enigmail,
and Mew) which call gpg command internally do NOT use --textmode even
when non-MIME encryption.

Regards,
-- 
Daiki Ueno

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Daiki Ueno]

[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]

>>>>> In <15566.1139355525@juniper.net> 
>>>>>	"Mark D. Baushke" <mdb@gnu.org> wrote:
> > See RFC3156, section 4:
> > 
> > 4.  OpenPGP encrypted data
> > 
> >    Before OpenPGP encryption, the data is written in MIME canonical
> >    format (body and headers).
> > 
> > Though I couldn't find the definition of "MIME canonical format", I
> > believe that it was intended to have CRLF line-ending.

> Hmmm... I also do not see the definition for "MIME canonical format"
> so I am not sure.

I found a clue in sylpheed-claws-users ML.
http://sourceforge.net/mailarchive/message.php?msg_id=1636575

  RFC 2045 (MIME) clearly says that CRLF is the normal line separator for
  MIME header fields. For body text, see RFC 2046 :
   
      The canonical form of any MIME "text" subtype MUST always represent a
      line break as a CRLF sequence.  Similarly, any occurrence of CRLF in
      MIME "text" MUST represent a line break.  Use of CR and LF outside of
      line break sequences is also forbidden.

> > > > For non-MIME encryption, line-ending conversion is not needed at all.
> > 
> > > I disagree. This is what started the debate in the first place.
> > 
> > > If I am sending a text message, then changing the line endings to CRLF
> > > as is done in pgg-gpg-encrypt-region should also tell the remote end
> > > that a text packet is coming rather than arbitrary binary data.
> > 
> > I doubt that it is really necessary to be a text packet.

Sorry, I misunderstood the problem.

Now my understanding is that, the problem is, unless --textmode is
specified, a sender and a receiver using non-MIME encryption have to
make an out-of-band agreement to specify line endings.  Right?

If so, --textmode is still needed for non-MIME encryption.  And also, if
"MIME canonical format" in RFC3156 is intended to have CRLF line
endings, specifying --textmode in PGP/MIME is harmless.

However, always specifying --textmode might not be a good idea.  Because
applications other than MUA will need encryption of raw binary data.

I attach a patch which allows users to select text-mode or binary-mode
by setting pgg-text-mode.


[-- Attachment #2: pgg-text-mode.diff --]
[-- Type: application/octet-stream, Size: 2132 bytes --]

Index: lisp/pgg-def.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/pgg-def.el,v
retrieving revision 7.9
diff -u -r7.9 pgg-def.el
--- lisp/pgg-def.el	8 Feb 2006 04:17:15 -0000	7.9
+++ lisp/pgg-def.el	8 Feb 2006 07:54:38 -0000
@@ -83,6 +83,9 @@
 (defvar pgg-scheme nil
   "Current scheme of PGP implementation.")
 
+(defvar pgg-text-mode nil
+  "If t, inform the recipient that the input is text.")
+
 (defmacro pgg-truncate-key-identifier (key)
   `(if (> (length ,key) 8) (substring ,key 8) ,key))
 
Index: lisp/pgg-gpg.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/pgg-gpg.el,v
retrieving revision 7.10
diff -u -r7.10 pgg-gpg.el
--- lisp/pgg-gpg.el	19 Jan 2006 11:53:12 -0000	7.10
+++ lisp/pgg-gpg.el	8 Feb 2006 07:54:38 -0000
@@ -185,7 +185,8 @@
 			    pgg-gpg-user-id))))
 	 (args
 	  (append
-	   (list "--batch" "--textmode" "--armor" "--always-trust" "--encrypt")
+	   (list "--batch" "--armor" "--always-trust" "--encrypt")
+	   (if pgg-text-mode (list "--textmode"))
 	   (if sign (list "--sign" "--local-user" pgg-gpg-user-id))
 	   (if recipients
 	       (apply #'nconc
@@ -213,7 +214,8 @@
 			 (pgg-read-passphrase
 			  "GnuPG passphrase for symmetric encryption: ")))
 	 (args
-	  (append (list "--batch" "--textmode" "--armor" "--symmetric" ))))
+	  (append (list "--batch" "--armor" "--symmetric" )
+		  (if pgg-text-mode (list "--textmode")))))
     (pgg-as-lbt start end 'CRLF
       (pgg-gpg-process-region start end passphrase pgg-gpg-program args))
     (pgg-process-when-success)))
@@ -277,9 +279,10 @@
 			  (format "GnuPG passphrase for %s: " pgg-gpg-user-id)
 			  pgg-gpg-user-id)))
 	 (args
-	  (list (if cleartext "--clearsign" "--detach-sign")
-		"--armor" "--batch" "--verbose"
-		"--local-user" pgg-gpg-user-id))
+	  (append (list (if cleartext "--clearsign" "--detach-sign")
+			"--armor" "--batch" "--verbose"
+			"--local-user" pgg-gpg-user-id)
+		  (if pgg-text-mode (list "--textmode"))))
 	 (inhibit-read-only t)
 	 buffer-read-only)
     (pgg-as-lbt start end 'CRLF

[-- Attachment #3: Type: text/plain, Size: 25 bytes --]


Regards,
-- 
Daiki Ueno

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

>>>>> In <7334ab51-5c86-4d97-92cb-21f2e7debd8d@well-done.deisui.org>
>>>>>	Daiki Ueno wrote:

> Now my understanding is that, the problem is, unless --textmode is
> specified, a sender and a receiver using non-MIME encryption have to
> make an out-of-band agreement to specify line endings.  Right?

> If so, --textmode is still needed for non-MIME encryption.  And also, if
> "MIME canonical format" in RFC3156 is intended to have CRLF line
> endings, specifying --textmode in PGP/MIME is harmless.

> However, always specifying --textmode might not be a good idea.  Because
> applications other than MUA will need encryption of raw binary data.

Currently, `pgg-gpg-encrypt-region' doesn't seem to support raw
binary data because it uses `pgg-as-lbt', which converts LF to
CRLF.  Should it be simply removed?

> I attach a patch which allows users to select text-mode or binary-mode
> by setting pgg-text-mode.

> +(defvar pgg-text-mode nil
> +  "If t, inform the recipient that the input is text.")

Even if it is useful, may we make it default to t?

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Daiki Ueno]

>>>>> In <b4m1wyei767.fsf@jpl.org> 
>>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> > However, always specifying --textmode might not be a good idea.  Because
> > applications other than MUA will need encryption of raw binary data.

> Currently, `pgg-gpg-encrypt-region' doesn't seem to support raw
> binary data because it uses `pgg-as-lbt', which converts LF to
> CRLF.  Should it be simply removed?

Just one suggestion: This change breaks API.  So it would be safe to
first make sure the caller of pgg-encrypt-region (i.e. Gnus' PGP/MIME
code) supplies input data which have CRLF line endings and then remove
pgg-as-lbt.

> > I attach a patch which allows users to select text-mode or binary-mode
> > by setting pgg-text-mode.

> > +(defvar pgg-text-mode nil
> > +  "If t, inform the recipient that the input is text.")

> Even if it is useful, may we make it default to t?

Hmm, I feel that it is natural to let the default be the same as GnuPG.

Regards,
-- 
Daiki Ueno

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

>>>>> In <086fafe1-6999-41f0-8a3d-cf042757aeef@well-done.deisui.org>
>>>>>	Daiki Ueno wrote:

>>> However, always specifying --textmode might not be a good idea.  Because
>>> applications other than MUA will need encryption of raw binary data.

>> Currently, `pgg-gpg-encrypt-region' doesn't seem to support raw
>> binary data because it uses `pgg-as-lbt', which converts LF to
>> CRLF.  Should it be simply removed?

> Just one suggestion: This change breaks API.  So it would be safe to
> first make sure the caller of pgg-encrypt-region (i.e. Gnus' PGP/MIME
> code) supplies input data which have CRLF line endings and then remove
> pgg-as-lbt.

I see.  But it seems to need a great effort, so I'm not quite
positive to do that now (that I'm not familiar with PGG is also
the reason to say so).  Do you have a will to do that?
Otherwise, how about doing it after Emacs 22.1 is released?

>>> I attach a patch which allows users to select text-mode or binary-mode
>>> by setting pgg-text-mode.

>>> +(defvar pgg-text-mode nil
>>> +  "If t, inform the recipient that the input is text.")

>> Even if it is useful, may we make it default to t?

> Hmm, I feel that it is natural to let the default be the same as GnuPG.

You're right.  However, Gnus users have been using it only with
text for a long time.

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daiki Ueno <ueno@unixuser.org> writes:

> >>>>> In <b4m1wyei767.fsf@jpl.org> 
> >>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> > > However, always specifying --textmode might not be a good idea.  Because
> > > applications other than MUA will need encryption of raw binary data.
> 
> > Currently, `pgg-gpg-encrypt-region' doesn't seem to support raw
> > binary data because it uses `pgg-as-lbt', which converts LF to
> > CRLF.  Should it be simply removed?
> 
> Just one suggestion: This change breaks API.  So it would be safe to
> first make sure the caller of pgg-encrypt-region (i.e. Gnus' PGP/MIME
> code) supplies input data which have CRLF line endings and then remove
> pgg-as-lbt.

Doing this means that you should add the --textmode switch as the line
endings would now be CRLF rather than being the native line ending that
GnuPG would be expecting.

> > > I attach a patch which allows users to select text-mode or binary-mode
> > > by setting pgg-text-mode.
> 
> > > +(defvar pgg-text-mode nil
> > > +  "If t, inform the recipient that the input is text.")
> 
> > Even if it is useful, may we make it default to t?
> 
> Hmm, I feel that it is natural to let the default be the same as GnuPG.

But this would only be true if you allow the files to have their natural
line endings.

If you need to force CRLF or use pgg-as-lbt on the region, then you also
need to inform GnuPG that the block is --textmode, or I am back to my
original problem. Even if you do introduce pgg-test-mode, I do not
understand how running the region through pgg-as-lbt before
pgg-gpg-encrypt-region is called allows me to encrypt binary data
attachments.

	Confused,
	-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFD6g31Cg7APGsDnFERAobjAJ4gab6rpfxtNsUANjluzioMNBCqiwCeIgPL
9u9VwPYOWbCsLor0aars4fo=
=bwCd
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Daiki Ueno]

>>>>> In <89375.1139412469@juniper.net> 
>>>>>	"Mark D. Baushke" <mdb@gnu.org> wrote:
> > > Currently, `pgg-gpg-encrypt-region' doesn't seem to support raw
> > > binary data because it uses `pgg-as-lbt', which converts LF to
> > > CRLF.  Should it be simply removed?
> > 
> > Just one suggestion: This change breaks API.  So it would be safe to
> > first make sure the caller of pgg-encrypt-region (i.e. Gnus' PGP/MIME
> > code) supplies input data which have CRLF line endings and then remove
> > pgg-as-lbt.

> Doing this means that you should add the --textmode switch as the line
> endings would now be CRLF rather than being the native line ending that
> GnuPG would be expecting.

I forgot this effect of --textmode.  Then, no API compatibility issue
should arise as long as pgg-text-mode is set properly.  The attached
patch should be sufficient for Gnus.

> If you need to force CRLF or use pgg-as-lbt on the region,

pgg-as-lbt is just redundant since there is no application which
requires implicit conversion of line-endings to CRLF _and_ to mark the
data as binary.

>>>>> In <b4mzml2fa3n.fsf@jpl.org> 
>>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> >>> I attach a patch which allows users to select text-mode or binary-mode
> >>> by setting pgg-text-mode.

> >>> +(defvar pgg-text-mode nil
> >>> +  "If t, inform the recipient that the input is text.")

> >> Even if it is useful, may we make it default to t?

> > Hmm, I feel that it is natural to let the default be the same as GnuPG.

> You're right.  However, Gnus users have been using it only with
> text for a long time.

Gnus users?  People who would become happy with enabling pgg-text-mode
by default are not Gnus users but (only a few) Gnus developers.  If a
Gnus developer properly set pgg-text-mode in his code, Gnus users need
not be aware of it.

So, I think it is not worth changing it.

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Daiki Ueno]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

>>>>> In <82f83936-8fb8-44a4-bb15-949ca44b6e72@well-done.deisui.org> 
>>>>>	Daiki Ueno <ueno@unixuser.org> wrote:
> I forgot this effect of --textmode.  Then, no API compatibility issue
> should arise as long as pgg-text-mode is set properly.  The attached
> patch should be sufficient for Gnus.

Sorry I forgot to attatch the patch.


[-- Attachment #2: pgg-text-mode.diff --]
[-- Type: application/octet-stream, Size: 5891 bytes --]

Index: lisp/ChangeLog
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/ChangeLog,v
retrieving revision 7.988
diff -u -r7.988 ChangeLog
--- lisp/ChangeLog	8 Feb 2006 12:05:31 -0000	7.988
+++ lisp/ChangeLog	8 Feb 2006 23:51:13 -0000
@@ -1,3 +1,18 @@
+2006-02-08  Daiki Ueno  <ueno@unixuser.org>
+
+	* pgg-gpg.el (pgg-gpg-encrypt-region): Don't convert line-endings
+	in elisp.
+	(pgg-gpg-encrypt-symmetric-region): Ditto.
+	(pgg-gpg-sign-region): Ditto.
+
+	* pgg-def.el (pgg-text-mode): New variable.
+
+	* mml2015.el (mml2015-pgg-sign): Enable pgg-text-mode.
+	(mml2015-pgg-encrypt): Ditto.
+
+	* mml1991.el (mml1991-pgg-sign): Enable pgg-text-mode.
+	(mml1991-pgg-encrypt): Ditto.
+
 2006-02-08  Katsumi Yamaoka  <yamaoka@jpl.org>
 
 	* rfc2231.el (rfc2231-parse-string): Sort segmented parameters;
Index: lisp/mml1991.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/mml1991.el,v
retrieving revision 7.7
diff -u -r7.7 mml1991.el
--- lisp/mml1991.el	8 Feb 2006 04:17:15 -0000	7.7
+++ lisp/mml1991.el	8 Feb 2006 23:51:13 -0000
@@ -229,7 +229,8 @@
   (defvar pgg-output-buffer))
 
 (defun mml1991-pgg-sign (cont)
-  (let (headers cte)
+  (let ((pgg-text-mode t)
+	headers cte)
     ;; Don't sign headers.
     (goto-char (point-min))
     (while (not (looking-at "^$"))
@@ -261,7 +262,8 @@
     t))
 
 (defun mml1991-pgg-encrypt (cont &optional sign)
-  (let (cte)
+  (let ((pgg-text-mode t)
+	cte)
     ;; Strip MIME Content[^ ]: headers since it will be ASCII ARMOURED
     (goto-char (point-min))
     (while (looking-at "^Content[^ ]+:")
Index: lisp/mml2015.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/mml2015.el,v
retrieving revision 7.13
diff -u -r7.13 mml2015.el
--- lisp/mml2015.el	8 Feb 2006 04:17:15 -0000	7.13
+++ lisp/mml2015.el	8 Feb 2006 23:51:13 -0000
@@ -818,6 +818,7 @@
 	(boundary (mml-compute-boundary cont))
 	(pgg-default-user-id (or (message-options-get 'mml-sender)
 				 pgg-default-user-id))
+	(pgg-text-mode t)
 	entry)
     (unless (pgg-sign-region (point-min) (point-max))
       (pop-to-buffer mml2015-result-buffer)
@@ -845,6 +846,7 @@
 
 (defun mml2015-pgg-encrypt (cont &optional sign)
   (let ((pgg-errors-buffer mml2015-result-buffer)
+	(pgg-text-mode t)
 	(boundary (mml-compute-boundary cont)))
     (unless (pgg-encrypt-region (point-min) (point-max)
 				(split-string
Index: lisp/pgg-def.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/pgg-def.el,v
retrieving revision 7.9
diff -u -r7.9 pgg-def.el
--- lisp/pgg-def.el	8 Feb 2006 04:17:15 -0000	7.9
+++ lisp/pgg-def.el	8 Feb 2006 23:51:13 -0000
@@ -83,6 +83,9 @@
 (defvar pgg-scheme nil
   "Current scheme of PGP implementation.")
 
+(defvar pgg-text-mode nil
+  "If t, inform the recipient that the input is text.")
+
 (defmacro pgg-truncate-key-identifier (key)
   `(if (> (length ,key) 8) (substring ,key 8) ,key))
 
Index: lisp/pgg-gpg.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/pgg-gpg.el,v
retrieving revision 7.10
diff -u -r7.10 pgg-gpg.el
--- lisp/pgg-gpg.el	19 Jan 2006 11:53:12 -0000	7.10
+++ lisp/pgg-gpg.el	8 Feb 2006 23:51:13 -0000
@@ -87,7 +87,9 @@
 	    (buffer-disable-undo)
 	    (erase-buffer)
 	    (if (file-exists-p output-file-name)
-		(let ((coding-system-for-read 'raw-text-dos))
+		(let ((coding-system-for-read (if pgg-text-mode
+						  'raw-text
+						'binary)))
 		  (insert-file-contents output-file-name)))
 	    (set-buffer errors-buffer)
 	    (if (not (equal exit-status 0))
@@ -185,7 +187,8 @@
 			    pgg-gpg-user-id))))
 	 (args
 	  (append
-	   (list "--batch" "--textmode" "--armor" "--always-trust" "--encrypt")
+	   (list "--batch" "--armor" "--always-trust" "--encrypt")
+	   (if pgg-text-mode (list "--textmode"))
 	   (if sign (list "--sign" "--local-user" pgg-gpg-user-id))
 	   (if recipients
 	       (apply #'nconc
@@ -194,8 +197,7 @@
 			      (append recipients
 				      (if pgg-encrypt-for-me
 					  (list pgg-gpg-user-id)))))))))
-    (pgg-as-lbt start end 'CRLF
-      (pgg-gpg-process-region start end passphrase pgg-gpg-program args))
+    (pgg-gpg-process-region start end passphrase pgg-gpg-program args)
     (when sign
       (with-current-buffer pgg-errors-buffer
 	;; Possibly cache passphrase under, e.g. "jas", for future sign.
@@ -213,9 +215,9 @@
 			 (pgg-read-passphrase
 			  "GnuPG passphrase for symmetric encryption: ")))
 	 (args
-	  (append (list "--batch" "--textmode" "--armor" "--symmetric" ))))
-    (pgg-as-lbt start end 'CRLF
-      (pgg-gpg-process-region start end passphrase pgg-gpg-program args))
+	  (append (list "--batch" "--armor" "--symmetric" )
+		  (if pgg-text-mode (list "--textmode")))))
+    (pgg-gpg-process-region start end passphrase pgg-gpg-program args)
     (pgg-process-when-success)))
 
 (defun pgg-gpg-decrypt-region (start end &optional passphrase)
@@ -277,13 +279,13 @@
 			  (format "GnuPG passphrase for %s: " pgg-gpg-user-id)
 			  pgg-gpg-user-id)))
 	 (args
-	  (list (if cleartext "--clearsign" "--detach-sign")
-		"--armor" "--batch" "--verbose"
-		"--local-user" pgg-gpg-user-id))
+	  (append (list (if cleartext "--clearsign" "--detach-sign")
+			"--armor" "--batch" "--verbose"
+			"--local-user" pgg-gpg-user-id)
+		  (if pgg-text-mode (list "--textmode"))))
 	 (inhibit-read-only t)
 	 buffer-read-only)
-    (pgg-as-lbt start end 'CRLF
-      (pgg-gpg-process-region start end passphrase pgg-gpg-program args))
+    (pgg-gpg-process-region start end passphrase pgg-gpg-program args)
     (with-current-buffer pgg-errors-buffer
       ;; Possibly cache passphrase under, e.g. "jas", for future sign.
       (pgg-gpg-possibly-cache-passphrase passphrase pgg-gpg-user-id)

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

>>>>> In <82f83936-8fb8-44a4-bb15-949ca44b6e72@well-done.deisui.org>
>>>>>	Daiki Ueno wrote:

> I forgot this effect of --textmode.  Then, no API compatibility issue
> should arise as long as pgg-text-mode is set properly.  The attached
> patch should be sufficient for Gnus.

[...]

>> You're right.  However, Gnus users have been using it only with
>> text for a long time.

> Gnus users?  People who would become happy with enabling pgg-text-mode
> by default are not Gnus users but (only a few) Gnus developers.  If a
> Gnus developer properly set pgg-text-mode in his code, Gnus users need
> not be aware of it.

> So, I think it is not worth changing it.

The new patch looks appropriate even to me who don't have a
great knowledge of PGG.  I've installed it just now.  Thanks.

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: multipart/mixed; boundary="==-=-=", Size: 3354 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --==-=-=
Content-Transfer-Encoding: quoted-printable

Well, the patch didn't work cleanly in my gnus-5.10.6 tree, so
I did this:

  cvs -d :pserver:gnus@cvs.gnus.org:/usr/local/cvsroot co -r v5-10 gnus
  cd gnus
  ./configure --prefix=3D~/elisp/gnus-5.10.6+cvs
  make
  make install

and then added the new directory to my load-path and re-compiled my
MH-E.

It may be due to the new version, but I am now seeing that mixing
a '#secure method=3Dpgp mode=3Dsignencrypt' section along with a
'#part type=3D"text/plain "filename=3D"~msg1.txt" disposition=3Dattachment
description=3D"a copy of the message as an attachment"'
'#/part'
(all inside angle brackets where appropraite) somehow only does a
mode=3Dencrypt on the message.)

I also notice that if I have a message with a 0x0D character in it or
full \r\n line endings and I just send a encrypted text message with
method=3Dpgp, that the resulting decoded message uses \n line endings on
my FreeBSD box and all 0x0D characters have been removed.

However, if I attach a DOS format file with \r\n line endings to a
message that has \r\n line endings, that the resulting decoded message
has a '=3D0xD' on the end of all of the lines that were originally \r\n
line endings.

	Thanks,
	-- Mark

The really odd thing about this mesage was that I secified

| <#secure method=3Dpgp mode=3Dsignencrypt sender=3D0x6B039C51>
| abc=0D
| efg=0D
| hij=0D
| =0D
| 	This file has control-M characters at the end of each line.=0D
|=20
- --==-=-=
Content-Disposition: attachment; filename=msg1.txt
Content-Transfer-Encoding: quoted-printable
Content-Description: a copy of the message as an attachment

abc=0D
efg=0D
hij=0D
=0D
	This file has control-M characters at the end of each line.=0D

- --==-=-=


the 'method=pgp mode=signencrypt' should have generated a signed and
encrypted message, but instead it only generated an encrypted message.


To: mdb@gnu.org
From: "Mark D. Baushke" <mdb@gnu.org>
Subject: test message
X-Mailer: MH-E 7.91+cvs; nmh 1.0.4; GNU Emacs 21.3.1
Date: Wed, 08 Feb 2006 22:33:40 -0800


[[PGP Encrypted Part:OK]]

- --=-=-=
Content-Transfer-Encoding: quoted-printable

abc=0D
efg=0D
hij=0D
=0D
	This file has control-M characters at the end of each line.=0D

- --=-=-=
Content-Disposition: attachment; filename=msg1.txt
Content-Transfer-Encoding: quoted-printable
Content-Description: a copy of the message as an attachment

abc=0D
efg=0D
hij=0D
=0D
	This file has control-M characters at the end of each line.=0D

- --=-=-=--

[[End of PGP Encrypted Part]]


For completeness, here is the MH-E version I am using:

M-x mh-version RET
MH-E 7.91+cvs

MH-E compilation details:
 Byte compiled:		yes
 Gnus (compile-time):	Gnus v5.10.7
 Gnus (run-time):	Gnus v5.10.7

GNU Emacs 21.3.1 (i386--freebsd, X toolkit, Xaw3d scroll bars)
 of 2003-07-11 on rat48.juniper.net

nmh 1.0.4
 mh-progs:	/usr/local/bin
 mh-lib:	/usr/local/etc/nmh
 mh-lib-progs:	/usr/local/libexec/nmh

FreeBSD sapphire.juniper.net 4.10-RELEASE-p2 FreeBSD 4.10-RELEASE-p2 #0: Wed Sep 15 14:24:39 PDT 2004     root@mailspare2.juniper.net:/usr/obj/usr/src/sys/mailspare2  i386

- --==-=-=--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFD6uPLCg7APGsDnFERAvrCAJwLYYwapxKZqBh110oYfHbmU1r65wCfQETf
hT8RO4C1zf1kC3itgVapRSg=
=mU3E
-----END PGP SIGNATURE-----

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


As an interesting side note that this last message I sent did not view
as having a signature that could be verified or not. I do not know if it
just MH-E that suffered from the probelm, or if you could see it too.

	Thanks,
	-- Mark

> From: "Mark D. Baushke" <mdb@gnu.org>
> To: Katsumi Yamaoka <yamaoka@jpl.org>
> cc: Daiki Ueno <ueno@unixuser.org>, ding@gnus.org,
>         mh-e-devel@lists.sourceforge.net
> Subject: Re: Gnus 5.10.6 problems with PGP/MIME (test cases) 
> In-Reply-To: <b4mk6c53wwn.fsf@jpl.org> 
> References: <19643.1137028354@juniper.net> <25107.1137439020@olgas.newt.com> <73630.1137440939@juniper.net> <b4m3bjnwbmi.fsf@jpl.org> <31430.1137488443@juniper.net> <b4mirsjjfc1.fsf@jpl.org> <85906.1137521874@juniper.net> <b4moe2ayua2.fsf@jpl.org> <53032.1137578648@juniper.net> <b4mpsmp3e11.fsf@jpl.org> <b258afad-11cd-4abc-99ba-89c99615ef53@well-done.deisui.org> <b4mek2fa9wu.fsf@jpl.org> <8b63142a-b090-4783-a3a5-0832d7289f38@well-done.deisui.org> <26653.1139305204@juniper.net> <9bda6607-510b-468c-bd1e-ec9b8865cdd2@well-done.deisui.org> <15566.1139355525@juniper.net> <7334ab51-5c86-4d97-92cb-21f2e7debd8d@well-done.deisui.org> <b4m1wyei767.fsf@jpl.org> <086fafe1-6999-41f0-8a3d-cf042757aeef@well-done.deisui.org> <89375.1139412469@juniper.net> <b4mzml2fa3n.fsf@jpl.org> <82f83936-8fb8-44a4-bb15-949ca44b6e72@well-done.deisui.org> <b4mk6c53wwn.fsf@jpl.org>
> X-Mailer: MH-E 7.91+cvs; nmh 1.0.4; GNU Emacs 21.3.1
> X-Face: #8D_6URD2G%vC.hzU<dI&#Y9szHj$'mGtUq&d=rXy^L$-=G_-LmZ^5!Fszk:yXZp$k\nTF?
>  8Up0!v/%1Q[(d?ES0mQW8dRCXi18gK)luJu)loHk,}4{Vi`yX?p?crF5o:LL{6#eiO:(E:YMxLXULB
>  k|'a*EjN.B&L+[J!PhJ*aX0n:5/
> Mail-Followup-To: mh-e-devel@lists.sourceforge.net
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="==-=-="
> Date: Wed, 08 Feb 2006 22:40:11 -0800
> Message-ID: <82735.1139467211@juniper.net>
> Sender: mdb@juniper.net
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> - --==-=-=
> Content-Transfer-Encoding: quoted-printable
> 
> Well, the patch didn't work cleanly in my gnus-5.10.6 tree, so
> I did this:
> 
>   cvs -d :pserver:gnus@cvs.gnus.org:/usr/local/cvsroot co -r v5-10 gnus
>   cd gnus
>   ./configure --prefix=3D~/elisp/gnus-5.10.6+cvs
>   make
>   make install
> 
> and then added the new directory to my load-path and re-compiled my
> MH-E.
> 
> It may be due to the new version, but I am now seeing that mixing
> a '#secure method=3Dpgp mode=3Dsignencrypt' section along with a
> '#part type=3D"text/plain "filename=3D"~msg1.txt" disposition=3Dattachment
> description=3D"a copy of the message as an attachment"'
> '#/part'
> (all inside angle brackets where appropraite) somehow only does a
> mode=3Dencrypt on the message.)
> 
> I also notice that if I have a message with a 0x0D character in it or
> full \r\n line endings and I just send a encrypted text message with
> method=3Dpgp, that the resulting decoded message uses \n line endings on
> my FreeBSD box and all 0x0D characters have been removed.
> 
> However, if I attach a DOS format file with \r\n line endings to a
> message that has \r\n line endings, that the resulting decoded message
> has a '=3D0xD' on the end of all of the lines that were originally \r\n
> line endings.
> 
> 	Thanks,
> 	-- Mark
> 
> The really odd thing about this mesage was that I secified
> 
> | <#secure method=3Dpgp mode=3Dsignencrypt sender=3D0x6B039C51>
> | abc=0D
> | efg=0D
> | hij=0D
> | =0D
> | 	This file has control-M characters at the end of each line.=0D
> |=20
> - --==-=-=
> Content-Disposition: attachment; filename=msg1.txt
> Content-Transfer-Encoding: quoted-printable
> Content-Description: a copy of the message as an attachment
> 
> abc=0D
> efg=0D
> hij=0D
> =0D
> 	This file has control-M characters at the end of each line.=0D
> 
> - --==-=-=
> 
> 
> the 'method=pgp mode=signencrypt' should have generated a signed and
> encrypted message, but instead it only generated an encrypted message.
> 
> 
> To: mdb@gnu.org
> From: "Mark D. Baushke" <mdb@gnu.org>
> Subject: test message
> X-Mailer: MH-E 7.91+cvs; nmh 1.0.4; GNU Emacs 21.3.1
> Date: Wed, 08 Feb 2006 22:33:40 -0800
> 
> 
> [[PGP Encrypted Part:OK]]
> 
> - --=-=-=
> Content-Transfer-Encoding: quoted-printable
> 
> abc=0D
> efg=0D
> hij=0D
> =0D
> 	This file has control-M characters at the end of each line.=0D
> 
> - --=-=-=
> Content-Disposition: attachment; filename=msg1.txt
> Content-Transfer-Encoding: quoted-printable
> Content-Description: a copy of the message as an attachment
> 
> abc=0D
> efg=0D
> hij=0D
> =0D
> 	This file has control-M characters at the end of each line.=0D
> 
> - --=-=-=--
> 
> [[End of PGP Encrypted Part]]
> 
> 
> For completeness, here is the MH-E version I am using:
> 
> M-x mh-version RET
> MH-E 7.91+cvs
> 
> MH-E compilation details:
>  Byte compiled:		yes
>  Gnus (compile-time):	Gnus v5.10.7
>  Gnus (run-time):	Gnus v5.10.7
> 
> GNU Emacs 21.3.1 (i386--freebsd, X toolkit, Xaw3d scroll bars)
>  of 2003-07-11 on rat48.juniper.net
> 
> nmh 1.0.4
>  mh-progs:	/usr/local/bin
>  mh-lib:	/usr/local/etc/nmh
>  mh-lib-progs:	/usr/local/libexec/nmh
> 
> FreeBSD sapphire.juniper.net 4.10-RELEASE-p2 FreeBSD 4.10-RELEASE-p2 #0: Wed Sep 15 14:24:39 PDT 2004     root@mailspare2.juniper.net:/usr/obj/usr/src/sys/mailspare2  i386
> 
> - --==-=-=--
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (FreeBSD)
> 
> iD8DBQFD6uPLCg7APGsDnFERAvrCAJwLYYwapxKZqBh110oYfHbmU1r65wCfQETf
> hT8RO4C1zf1kC3itgVapRSg=
> =mU3E
> -----END PGP SIGNATURE-----
> --==-=-=--

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFD6uS3Cg7APGsDnFERAvJ5AKCQHnT0GIwSGMU9uJ2TaM0Uh8PBBgCgrKN/
9e1f2infmd8k+8R2EPKNt90=
=zP2i
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Katsumi Yamaoka]

>>>>> In <82857.1139467447@juniper.net> Mark D. Baushke wrote:

> As an interesting side note that this last message I sent did not view
> as having a signature that could be verified or not. I do not know if it
> just MH-E that suffered from the probelm, or if you could see it too.

That message seems to have been signed after composing as a
multipart message.  The message was labeled as multipart/mixed,
so it will not be dissected into some parts by mm-uu.el, which
dissects only messages labeled with text/* (and application/pgp
as well).  Although I don't know the way to compose such message
properly using MH-E plus Gnus, I (and probably Ueno-san) can read
it.

Re: Gnus 5.10.6 problems with PGP/MIME (test cases)

[Mark D. Baushke]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: multipart/mixed; boundary="=-=-=", Size: 1386 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --=-=-=
Content-Transfer-Encoding: quoted-printable

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> >>>>> In <82857.1139467447@juniper.net> Mark D. Baushke wrote:
>=20
> > As an interesting side note that this last message I sent did not view
> > as having a signature that could be verified or not. I do not know if it
> > just MH-E that suffered from the probelm, or if you could see it too.
>=20
> That message seems to have been signed after composing as a
> multipart message.  The message was labeled as multipart/mixed,
> so it will not be dissected into some parts by mm-uu.el, which
> dissects only messages labeled with text/* (and application/pgp
> as well).  Although I don't know the way to compose such message
> properly using MH-E plus Gnus, I (and probably Ueno-san) can read
> it.

It seems that using a method=3Dpgpmime is the only reasonable solution for
this one.

	Thanks,
	-- Mark


- --=-=-=
Content-Disposition: attachment; filename=msg1.txt
Content-Transfer-Encoding: quoted-printable
Content-Description: a test attachment

abc=0D
efg=0D
hij=0D
=0D
	This file has control-M characters at the end of each line.=0D

- --=-=-=--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFD6vJICg7APGsDnFERAoaNAKCisCSfRPuxhKTM6yyu9rMF7d+n5wCgorXZ
43VCSqCni5XF82nzJrE0BaM=
=PYzT
-----END PGP SIGNATURE-----

refered article lookup (was: Gnus 5.10.6 problems with PGP/MIME (test cases))

[Jochen Küpper]

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

"Mark D. Baushke" <mdb-mXXj517/zsQ@public.gmane.org> writes:

> As an interesting side note that this last message I sent did not
> view as having a signature that could be verified or not.

Ok, so I try it... Press "^" (gnus-summary-refer-parent-article) to
get the article. With this setting

,----[ C-h v gnus-refer-article-method RET ]
| gnus-refer-article-method is a variable defined in `gnus.el'.
| Its value is 
| (current
|  (nntp "news.rz-berlin.mpg.de")
|  (nntp "news.gmane.org")
|  (nnweb "google"
|         (nnweb-type 'google)))
[...]
`----

I wonder why I get it from Gmane and not the local nnimap group, where
I read and store ding? Anyway...

Ok, so the message does not look decoded right, so I select a
different message (i.e. the child) and reselect the parent in the
summary buffer, but nothing is displayed... That's the messages I get:
,----[*Messages*]
[...]
| Auto-saving...done
| Mark set
| Opening nntp server on news.rz-berlin.mpg.de...
| Denied server
| Opening nntp server on news.rz-berlin.mpg.de...failed
| apply: Server closed connection
| Mark set
`----

I am using 
,----
| GNU Emacs 22.0.50.4 (i686-pc-linux-gnu, GTK+ Version 2.4.14) of 2006-02-07
| No Gnus v0.4 (cvs HEAD of 2006-02-07)
`----

I would expect to at least be able to redisplay the article as long as
I don't quit the group. Why does that not work?

Anything I am doing wrong?

Any additional information I should send?

Greetings,
Jochen
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: refered article lookup

[Katsumi Yamaoka]

>>>>> In <9eu0b9543r.fsf_-_@doze.jochen-kuepper.de> Jochen Küpper wrote:

> "Mark D. Baushke" <mdb@gnu.org> writes:

>> As an interesting side note that this last message I sent did not
>> view as having a signature that could be verified or not.

> Ok, so I try it... Press "^" (gnus-summary-refer-parent-article) to
> get the article. With this setting

[...]

> I wonder why I get it from Gmane and not the local nnimap group, where
> I read and store ding? Anyway...

Maybe delivering the article to the ding list was deferred or
failed for some reason.  I've received only the article sent to
me directly.