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

["Mark D. Baushke" <mdb@gnu.org>]

-----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