Large *.pif base64 attachments and Gnus...

Large *.pif base64 attachments and Gnus...

[Pavel Janík]

Hi,

you probably see the same behaviour of our Outlook colleges sending us big
.doc.pif files ;-) I'm trying to save them to a file with `o' on the MIME
button. It is saved to file I specify, but it is not decoded. It is saved
as raw base64 data, no error message can be seen, no beep for normal
user. Only this can be seen in *Messages*:

Error while decoding: (error Invalid base64 data)
Wrote /tmp/tlm-doc.zip.pif

I can provide sample of course, but I think you have already received many
of them ;-)

I think that: 1. we should clearly warn user about base64 error.
              2. not save anything if there is an error.

What do you think?
-- 
Pavel Janík

/* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any
 * way.
 */
                  -- 2.4.3 net/core/netfilter.c

Re: Large *.pif base64 attachments and Gnus...

[Russ Allbery]

Pavel Janík <Pavel@Janik.cz> writes:

> you probably see the same behaviour of our Outlook colleges sending us
> big .doc.pif files ;-) I'm trying to save them to a file with `o' on the
> MIME button.

This is almost certainly the SirCam virus, just so that you know.
(There's very rarely any reason for anyone to send you a .pif file; .pif
is the extension for a control file specifying how to run a DOS program
under Windows, IIRC.)  The .doc.pif bit in particular gives this away as
SirCam.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Large *.pif base64 attachments and Gnus...

[Pavel Janík]

   From: Russ Allbery <rra@stanford.edu>
   Date: 02 Aug 2001 17:57:25 -0700

Hi,

   > > you probably see the same behaviour of our Outlook colleges sending us
   > > big .doc.pif files ;-) I'm trying to save them to a file with `o' on the
   > > MIME button.
   > 
   > This is almost certainly the SirCam virus, just so that you know.
   > (There's very rarely any reason for anyone to send you a .pif file; .pif
   > is the extension for a control file specifying how to run a DOS program
   > under Windows, IIRC.)  The .doc.pif bit in particular gives this away as
   > SirCam.

of course I know this is SirCam. See the `;-)' at the end of sentence. The
thing I'm trying to solve on the list of Gnus developers is to fix the
apparent bug in Gnus which saves an article as plain base64 bytes without
decoding... Just try it yourself and tell me, if it works for you. I;d like
to really SEE the contents of the file they sent me...
-- 
Pavel Janík

Be warned: emacs has a steep upward learning curve.
                  -- a.l.meyers@consult-meyers.com in gnu.emacs.help

Re: Large *.pif base64 attachments and Gnus...

[Florian Weimer]

Pavel@Janik.cz (Pavel Janík) writes:

> of course I know this is SirCam. See the `;-)' at the end of sentence. The
> thing I'm trying to solve on the list of Gnus developers is to fix the
> apparent bug in Gnus which saves an article as plain base64 bytes without
> decoding... Just try it yourself and tell me, if it works for you.

It is a bug in 'base64-decode-region'.  Perhaps it's fixed in Emacs
21, I don't know.  The base64 encoding is indeed incorrect, and that's
why such stuff slips through quite a few mail inspection tools; but
'base64-decode-region' does not signal the error, but simply does
nothing.

> I;d like to really SEE the contents of the file they sent me...

Try mimencode, which comes with metamail.  It is more tolerant.

Re: Large *.pif base64 attachments and Gnus...

[Pavel Janík]

   From: Florian Weimer <fw@deneb.enyo.de>
   Date: Sat, 04 Aug 2001 17:51:10 +0200

Hi,

   > > of course I know this is SirCam. See the `;-)' at the end of sentence. The
   > > thing I'm trying to solve on the list of Gnus developers is to fix the
   > > apparent bug in Gnus which saves an article as plain base64 bytes without
   > > decoding... Just try it yourself and tell me, if it works for you.
   > 
   > It is a bug in 'base64-decode-region'.  Perhaps it's fixed in Emacs
   > 21, I don't know.  The base64 encoding is indeed incorrect, and that's

huh, I use 21 :-( So I will report this bug to appropriate mailing
list. Thank you.

   > > I;d like to really SEE the contents of the file they sent me...
   > 
   > Try mimencode, which comes with metamail.  It is more tolerant.

I should be more precise in the future :-) I'd like to really SEE the
contents of the file they sent me in Gnus.
-- 
Pavel Janík

After 40 Terabytes, your fingers start to hurt.
                  -- David Miller about typing

Re: Large *.pif base64 attachments and Gnus...

[Simon Josefsson]

Pavel@Janik.cz (Pavel Janík) writes:

>    From: Florian Weimer <fw@deneb.enyo.de>
>
>   > It is a bug in 'base64-decode-region'.  Perhaps it's fixed in Emacs
>   > 21, I don't know.  The base64 encoding is indeed incorrect, and that's
> 
> huh, I use 21 :-( So I will report this bug to appropriate mailing
> list. Thank you.

No, there's nothing wrong with `base64-decode-region', Gnus simply
catches the error and message it.  Does the following help?

Btw, the error with the b64 encoding is that it ends with "===", which
is invalid. Maybe the b64 parser should be made able to cope with that
simple error.

Index: mm-decode.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/mm-decode.el,v
retrieving revision 6.48
diff -u -u -w -u -w -r6.48 mm-decode.el
--- mm-decode.el	2001/08/04 00:33:18	6.48
+++ mm-decode.el	2001/08/04 23:31:56
@@ -891,20 +891,22 @@
       (if (member (mm-handle-media-supertype handle) '("text" "message"))
 	  (with-temp-buffer
 	    (insert-buffer-substring (mm-handle-buffer handle))
+	    (prog1
 	    (mm-decode-content-transfer-encoding
 	     (mm-handle-encoding handle)
 	     (mm-handle-media-type handle))
 	    (let ((temp (current-buffer)))
 	      (set-buffer cur)
-	      (insert-buffer-substring temp)))
+		(insert-buffer-substring temp))))
 	(mm-with-unibyte-buffer
 	  (insert-buffer-substring (mm-handle-buffer handle))
+	  (prog1
 	  (mm-decode-content-transfer-encoding
 	   (mm-handle-encoding handle)
 	   (mm-handle-media-type handle))
 	  (let ((temp (current-buffer)))
 	    (set-buffer cur)
-	    (insert-buffer-substring temp)))))))
+	      (insert-buffer-substring temp))))))))
 
 (defun mm-file-name-delete-whitespace (file-name)
   "Remove all whitespace characters from FILE-NAME."
@@ -959,7 +961,8 @@
 
 (defun mm-save-part-to-file (handle file)
   (mm-with-unibyte-buffer
-    (mm-insert-part handle)
+    (or (mm-insert-part handle)
+	(error "Error with message"))
     (let ((coding-system-for-write 'binary)
 	  ;; Don't re-compress .gz & al.  Arguably we should make
 	  ;; `file-name-handler-alist' nil, but that would chop

Re: Large *.pif base64 attachments and Gnus...

[Florian Weimer]

Simon Josefsson <jas@extundo.com> writes:

>>   > It is a bug in 'base64-decode-region'.  Perhaps it's fixed in Emacs
>>   > 21, I don't know.  The base64 encoding is indeed incorrect, and that's
>> 
>> huh, I use 21 :-( So I will report this bug to appropriate mailing
>> list. Thank you.
> 
> No, there's nothing wrong with `base64-decode-region', Gnus simply
> catches the error and message it.

On Emacs 20, there is. ;-)

Re: Large *.pif base64 attachments and Gnus...

[Pavel Janík]

   From: Simon Josefsson <jas@extundo.com>
   Date: Sun, 05 Aug 2001 01:36:48 +0200

Hi,

   > >   > It is a bug in 'base64-decode-region'.  Perhaps it's fixed in Emacs
   > >   > 21, I don't know.  The base64 encoding is indeed incorrect, and that's
   > > 
   > > huh, I use 21 :-( So I will report this bug to appropriate mailing
   > > list. Thank you.
   > 
   > No, there's nothing wrong with `base64-decode-region', Gnus simply
   > catches the error and message it.  Does the following help?
   > 
   > Btw, the error with the b64 encoding is that it ends with "===", which
   > is invalid. Maybe the b64 parser should be made able to cope with that
   > simple error.
   > 
   > Index: mm-decode.el
   > ===================================================================
   > RCS file: /usr/local/cvsroot/gnus/lisp/mm-decode.el,v
   > retrieving revision 6.48
   > diff -u -u -w -u -w -r6.48 mm-decode.el
   > --- mm-decode.el	2001/08/04 00:33:18	6.48
   > +++ mm-decode.el	2001/08/04 23:31:56

yes, this will signal an appropriate error to the user.
-- 
Pavel Janík

kwintv is always crashing. Please fix it fast.. I want to watch Star Trek.
                  -- Thomas Biege <thomas@suse.de>

Re: Large *.pif base64 attachments and Gnus...

[Simon Josefsson]

Pavel@Janik.cz (Pavel Janík) writes:

>    > No, there's nothing wrong with `base64-decode-region', Gnus simply
>    > catches the error and message it.  Does the following help?
>
> yes, this will signal an appropriate error to the user.

Committed.  If `base64-decode-region' is broken in Emacs 20 it doesn't
help though.

Re: Large *.pif base64 attachments and Gnus...

[Florian Weimer]

Simon Josefsson <jas@extundo.com> writes:

> Committed.  If `base64-decode-region' is broken in Emacs 20 it doesn't
> help though.

I finally managed to look at the documentation, and it's strange
behavior is even documented:

| Base64-decode the region between BEG and END.
| Return the length of the decoded text.
| If the region can't be decoded, return nil and don't modify the buffer.

Is this different on Emacs 21?

Re: Large *.pif base64 attachments and Gnus...

[Simon Josefsson]

Florian Weimer <fw@deneb.enyo.de> writes:

>> Committed.  If `base64-decode-region' is broken in Emacs 20 it doesn't
>> help though.
>
> I finally managed to look at the documentation, and it's strange
> behavior is even documented:
>
> | Base64-decode the region between BEG and END.
> | Return the length of the decoded text.
> | If the region can't be decoded, return nil and don't modify the buffer.
>
> Is this different on Emacs 21?

Yes.  I think the current code should work with both schemes.

base64-decode-region is an interactive built-in function.
(base64-decode-region BEG END)

Base64-decode the region between BEG and END.
Return the length of the decoded text.
If the region can't be decoded, signal an error and don't modify the buffer.