Disable mailcap support

Disable mailcap support

[Florian Weimer]

After some discussion with RMS after he posted
<mailman.944.1061837187.29551.info-gnu@gnu.org>, we have come to the
conclusion that it might be a good idea to disable mailcap processing.

Reiner Steib kindly wrote the patch reproduced, which makes Gnus'
behavior more configurable.

I'd like to see 'mm-enable-external' disabled in the default
configuration, but my judgement in such matters is typically quite
drastic.  Comments?

--- mm-decode.el.~6.94.~	Thu Aug 28 11:06:58 2003
+++ mm-decode.el	Mon Sep 22 22:42:34 2003
@@ -151,6 +151,18 @@
   :type 'boolean
   :group 'mime-display)
 
+(defcustom mm-enable-external t
+  "Indicate if external MIME handlers should be used.
+
+If t, all defined external MIME handlers are used.  If nil, files are saved by
+`mailcap-save-binary-file'.  If it is the symbol `ask', you are prompted
+before the external MIME handler is invoked."
+  :version "21.4"
+  :type '(choice (const :tag "Always" t)
+		 (const :tag "Never" nil)
+		 (const :tag "Ask" ask))
+  :group 'mime-display)
+
 (defcustom mm-inline-media-tests
   '(("image/jpeg"
      mm-inline-image
@@ -619,7 +631,12 @@
     (if (mm-handle-displayed-p handle)
 	(mm-remove-part handle)
       (let* ((type (mm-handle-media-type handle))
-	     (method (mailcap-mime-info type)))
+	     (method (mailcap-mime-info type))
+	     (filename (or (mail-content-type-get
+			    (mm-handle-disposition handle) 'filename)
+			   (mail-content-type-get
+			    (mm-handle-type handle) 'name)
+			   "<file>")))
 	(if (and (mm-inlinable-p handle)
 		 (mm-inlined-p handle))
 	    (progn
@@ -634,8 +651,20 @@
 		  (forward-line 1)
 		  (mm-insert-inline handle (mm-get-part handle))
 		  'inline)
-	      (mm-display-external
-	       handle (or method 'mailcap-save-binary-file)))))))))
+	      (cond
+	       ((eq mm-enable-external 'ask)
+		(if (and method
+			 (y-or-n-p (concat
+				    "Display part using external program `"
+				    (format method filename) "'? ")))
+		    (mm-display-external handle method)
+		  (mm-display-external handle 'mailcap-save-binary-file)))
+	       (mm-enable-external
+		(mm-display-external
+		 handle (or method 'mailcap-save-binary-file)))
+	       (t
+		(mm-display-external
+		 handle 'mailcap-save-binary-file))))))))))
 
 (defun mm-display-external (handle method)
   "Display HANDLE using METHOD."

Re: Disable mailcap support

[Jesper Harder]

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

> After some discussion with RMS after he posted:

RMS>   2. We did not make the incredibly stupid decision to design
RMS>   applications so that they execute programs that arrive in the mail.
RMS>
RMS> [..] If you know the journalists who might write about this, it
RMS> would be useful to to talk with them before they write their
RMS> stories.

@digression

I think there's a bit of hybris in that statement.  If I were a
journalist, I'd be asking questions like:

* Many viruses exploit user stupidity/naiveté rather than technical
  flaws.  Does switching to free software automatically make you less
  stupid?

* Are LaTeX files less prone to macro viruses than Microsoft Word
  files?

* Why is the `eval' file variable in Emacs any safer than the ability
  to launch an exe file from Outlook Express[1]?

@end digression

> we have come to the conclusion that it might be a good idea to
> disable mailcap processing.
>
> I'd like to see 'mm-enable-external' disabled in the default
> configuration, but my judgement in such matters is typically quite
> drastic.

Why should we a priori consider, say, xdvi less safe than some of the
libraries (libpng, libtiff, zlib etc.) that Emacs is built against?


[1] Actually, you can't do this any more in OE, you're not even
    allowed to save it to disk.

Re: Disable mailcap support

[Florian Weimer]

On Mon, Sep 29, 2003 at 12:56:29AM +0200, Jesper Harder wrote:

> Why should we a priori consider, say, xdvi less safe than some of the
> libraries (libpng, libtiff, zlib etc.) that Emacs is built against?

xdvi can invoke Netscape or Mozilla, the libraries don't do _that_. 8-)

But I see your point.  Maybe image support should be disabled, too?
At least the pictures should not be shown by default (certainly a good
idea anyway because of some junk mail).

Re: Disable mailcap support

[Jesper Harder]

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

> Jesper Harder wrote:
>
>> Why should we a priori consider, say, xdvi less safe than some of the
>> libraries (libpng, libtiff, zlib etc.) that Emacs is built against?
>
> xdvi can invoke Netscape or Mozilla, the libraries don't do _that_. 8-)
>
> But I see your point.

I'm not sure I understand your point about mailcap.  Could you
explain it a bit more?

I'd have thought disabling mailcap is less safe.  When you launch an
attachment through mailcap an attempt is made to use a safe viewer
with the safest options -- this isn't the case if you save it to disk
and launch it in a different way (command line or double-clicking).

> Maybe image support should be disabled, too?  At least the pictures
> should not be shown by default (certainly a good idea anyway because
> of some junk mail).

In my experience almost all junk mail that includes pictures are
text/html, so this is something that should be configured in the HTML
renderer.

Re: Disable mailcap support

[Florian Weimer]

Jesper Harder wrote:

> I'm not sure I understand your point about mailcap.  Could you
> explain it a bit more?

Mailcap implements a "primary verb" on objects whose type (and thus the
action triggered by the verb) is not known to the user.  The user
invokes applications which he has never run before.

Experience shows that this leads to countless users shooting themselves
into their feet.  

> I'd have thought disabling mailcap is less safe.  When you launch an
> attachment through mailcap an attempt is made to use a safe viewer
> with the safest options -- this isn't the case if you save it to disk
> and launch it in a different way (command line or double-clicking).

Yes, that's an interesting situation.  Typical invocations omit options
like -dSAFER.  So it's essentially unfixable. *sigh*

Re: Disable mailcap support

[Reiner Steib]

On Mon, Sep 29 2003, Jesper Harder wrote:

> Florian Weimer <fw@deneb.enyo.de> writes:
[...]
>> xdvi can invoke Netscape or Mozilla, the libraries don't do _that_. 8-)
>>
>> But I see your point.
>
> I'm not sure I understand your point about mailcap.  Could you
> explain it a bit more?
>
> I'd have thought disabling mailcap is less safe.  When you launch an
> attachment through mailcap an attempt is made to use a safe viewer
> with the safest options -- this isn't the case if you save it to disk
> and launch it in a different way (command line or double-clicking).

I have installed a possibility to disable external viewers as
suggested in the initial posting in this thread.  The default behavior
is _unchanged_, unless the user customizes `mm-enable-external'.  I
took over a part Jesper's text into the manual:

,----[ (info "(emacs-mime)Display Customization") ]
| `mm-enable-external'
|      Indicate whether external MIME handlers should be used.
| 
|      If `t', all defined external MIME handlers are used.  If `nil',
|      files are saved to disk (`mailcap-save-binary-file').  If it is
|      the symbol `ask', you are prompted before the external MIME
|      handler is invoked.
| 
|      When you launch an attachment through mailcap (*note mailcap::) an
|      attempt is made to use a safe viewer with the safest options-this
|      isn't the case if you save it to disk and launch it in a different
|      way (command line or double-clicking).  Anyhow, if you want to be
|      sure not to launch any external programs, set this variable to
|      `nil' or `ask'.
`----

I hope this is okay for everyone.

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

Re: Disable mailcap support

[Reiner Steib]

On Sun, Sep 28 2003, Florian Weimer wrote:

> After some discussion with RMS after he posted
> <mailman.944.1061837187.29551.info-gnu@gnu.org>, we have come to the
> conclusion that it might be a good idea to disable mailcap processing.
>
> Reiner Steib kindly wrote the patch reproduced, which makes Gnus'
> behavior more configurable.

Here's another patch, allowing additional regexp and function values
for `mm-enable-external':

--8<---------------cut here---------------start------------->8---
--- mm-decode.el.~6.94.~	Thu Aug 28 11:06:58 2003
+++ mm-decode.el	Mon Sep 29 21:19:14 2003
@@ -151,6 +151,27 @@
   :type 'boolean
   :group 'mime-display)
 
+(defcustom mm-enable-external 'ask
+  "Indicate which external MIME handlers should be used.
+
+If t, all defined external MIME handlers are used.  If nil, files are saved by
+`mailcap-save-binary-file'.  If it is the symbol `ask', you are prompted
+before the external MIME handler is invoked.
+
+If `mm-enable-external' is a function, that function is called with three
+arguments: the MIME type, the method and the filename for this MIME handle.
+The external MIME handler is invoked, iff this function returns non-nil.
+
+If if `mm-enable-external' is a regular expression, the external MIME handler
+is invoked, iff the MIME type is matches the expression."
+  :version "21.4"
+  :type '(choice (const :tag "Always" t)
+		 (const :tag "Never" nil)
+		 (const :tag "Ask" ask)
+		 (function :tag "A function")
+		 (regexp :tag "Regexp"))
+  :group 'mime-display)
+
 (defcustom mm-inline-media-tests
   '(("image/jpeg"
      mm-inline-image
@@ -619,7 +640,13 @@
     (if (mm-handle-displayed-p handle)
 	(mm-remove-part handle)
       (let* ((type (mm-handle-media-type handle))
-	     (method (mailcap-mime-info type)))
+	     (method (mailcap-mime-info type))
+	     (filename (or (mail-content-type-get
+			    (mm-handle-disposition handle) 'filename)
+			   (mail-content-type-get
+			    (mm-handle-type handle) 'name)
+			   "<file>"))
+	     (external mm-enable-external))
 	(if (and (mm-inlinable-p handle)
 		 (mm-inlined-p handle))
 	    (progn
@@ -634,8 +661,28 @@
 		  (forward-line 1)
 		  (mm-insert-inline handle (mm-get-part handle))
 		  'inline)
-	      (mm-display-external
-	       handle (or method 'mailcap-save-binary-file)))))))))
+	      (if (and method ;; If nil, we always use "save".
+		       (stringp method) ;; 'mailcap-save-binary-file
+		       (or (and (eq mm-enable-external 'ask)
+				(y-or-n-p
+				 (concat
+				  "Display part (" type
+				  ") using external program \""
+				  (format method filename) "\"? ")))
+			   (and (stringp mm-enable-external)
+				(string-match mm-enable-external type))
+			   (and (symbolp mm-enable-external)
+				(fboundp mm-enable-external)
+				(funcall mm-enable-external
+					 type method filename))
+			   nil))
+		  (setq external t)
+		(setq external nil))
+	      (if external
+		  (mm-display-external
+		   handle (or method 'mailcap-save-binary-file))
+		(mm-display-external
+		 handle 'mailcap-save-binary-file)))))))))
 
 (defun mm-display-external (handle method)
   "Display HANDLE using METHOD."
@@ -656,7 +703,8 @@
 	    (mm-set-buffer-file-coding-system mm-binary-coding-system)
 	    (insert-buffer-substring cur)
 	    (goto-char (point-min))
-	    (message "Viewing with %s" method)
+	    (when method
+	      (message "Viewing with %s" method))
 	    (let ((mm (current-buffer))
 		  (non-viewer (assq 'non-viewer
 				    (mailcap-mime-info
--8<---------------cut here---------------end--------------->8---

The last hunk is independent from the current subject: It makes no
sense to say "Viewing with nil" when the part is saved to disk.

> I'd like to see 'mm-enable-external' disabled in the default
> configuration, but my judgement in such matters is typically quite
> drastic.  Comments?

`mm-enable-external' is Gnus' current behavior.  My preference is
`ask' which is not as drastic as Florian's suggestion, but it allows
the user to see which external program will be invoked.

Maybe we should also think about this comment in `mailcap.el' before
the defvar of `mailcap-mime-data':

;; Postpone using defcustom for this as it's so big and we essentially
;; have to have two copies of the data around then.  Perhaps just
;; customize the Lisp viewers and rely on the normal configuration
;; files for the rest?  -- fx

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

Re: Disable mailcap support

[Jesper Harder]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> Here's another patch, allowing additional regexp and function values
> for `mm-enable-external':
>
> +If `mm-enable-external' is a function, that function is called with
> +three arguments: the MIME type, the method and the filename for
> +this MIME handle.  The external MIME handler is invoked, iff this
> +function returns non-nil.
> +
> +If if `mm-enable-external' is a regular expression, the external
> +MIME handler is invoked, iff the MIME type is matches the
> +expression."

I don't understand the purpose.  This is exactly what mailcap is
intended to do -- that is if you don't want to invoke an external
viewer for some MIME type, then edit your .mailcap file to reflect
that preference.

Re: Disable mailcap support

[Reiner Steib]

On Mon, Sep 29 2003, Jesper Harder wrote:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>
>> Here's another patch, allowing additional regexp and function values
>> for `mm-enable-external':
[...]
> I don't understand the purpose.  This is exactly what mailcap is
> intended to do -- that is if you don't want to invoke an external
> viewer for some MIME type, then edit your .mailcap file to reflect
> that preference.

Gnus adds many entries (~43) to `mailcap-mime-data'.  Most of them are
not present in my mailcap files.  I've been unable to find a simple
way of removing the entire entries created by Gnus.

Or suppose a user wants to display all kind of images (internally or
externally), but always save dvi, ps, pdf, ... to a file.  What should
the user put in his mailcap files?  _Not_ having entries for dvi, ps,
pdf should be enough.

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

Re: Disable mailcap support

[Jesper Harder]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> On Mon, Sep 29 2003, Jesper Harder wrote:
>
>> I don't understand the purpose.  This is exactly what mailcap is
>> intended to do -- that is if you don't want to invoke an external
>> viewer for some MIME type, then edit your .mailcap file to reflect
>> that preference.
>
> Gnus adds many entries (~43) to `mailcap-mime-data'.  Most of them are
> not present in my mailcap files.  I've been unable to find a simple
> way of removing the entire entries created by Gnus.

  (setq mailcap-mime-data nil)

?

> Or suppose a user wants to display all kind of images (internally or
> externally), but always save dvi, ps, pdf, ... to a file.  What should
> the user put in his mailcap files?

Saving to a file is an internal function, so you can't specify it in
mailcap, but

  (mailcap-add "application/pdf" 'mailcap-save-binary-file)

etc. should work fine.

> _Not_ having entries for dvi, ps, pdf should be enough.

I think I agree.  But I don't understand why there are external
viewers in `mailcap-mime-data' in the first place.  If no one knows a
good reason I think we should remove them (and use defcustom).

Re: Disable mailcap support

[Reiner Steib]

On Wed, Oct 01 2003, Jesper Harder wrote:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>> I've been unable to find a simple way of removing the entire
>> entries created by Gnus.
>
>   (setq mailcap-mime-data nil)

This also disables entries from the mailcap files... *oops* ... only
if eval'ed after `mailcap-parsed-p' has been set to t already.

>> Or suppose a user wants to display all kind of images (internally or
>> externally), but always save dvi, ps, pdf, ... to a file.  What should
>> the user put in his mailcap files?
[...]
>   (mailcap-add "application/pdf" 'mailcap-save-binary-file)
[...]
>> _Not_ having entries for dvi, ps, pdf should be enough.
>
> I think I agree.  But I don't understand why there are external
> viewers in `mailcap-mime-data' in the first place.  

It seems (from the ChangeLog entries for `mailcap-mime-data') that
most entries are quite old.  Does anyone remember why there are so
many external entries?  Maybe because the system mailcap files didn't
contain anything useful.

> If no one knows a good reason I think we should remove them (and use
> defcustom).

I.e. basically follow Dave Love's suggestion?

| Postpone using defcustom for this as it's so big and we essentially
| have to have two copies of the data around then.  Perhaps just
| customize the Lisp viewers and rely on the normal configuration
| files for the rest?  -- fx

(Just a thought...)  We could split the data as follows:
- defcustom mailcap-mime-data-internal (Lisp, PGP, message/* and other
  internal stuff?)
- defvar mailcap-mime-data-external (build this from mailcap files)
- defvar mailcap-mime-data-external-fallback

The default should be mailcap-mime-data = mailcap-mime-data-internal +
mailcap-mime-data-external.  The user should be able to add the
fallback entries `mailcap-mime-data-external-fallback' with, say
(mailcap-add-fallback).  I'm not sure about the print stuff and "(test
. (fboundp 'foo-mode))" and similar.  `mailcap.el' is used by other
packages too (w3, url, mh-e, vm, ...), so we should be extra careful.

Bye, Reiner.

P.S.: Beside `mailcap-mime-data', we also have
      `gnus-uu-default-view-rules', see the `X v ...' commands. :-/
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Disable mailcap support

[Jesper Harder]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> On Wed, Oct 01 2003, Jesper Harder wrote:
>
>> I think I agree.  But I don't understand why there are external
>> viewers in `mailcap-mime-data' in the first place.  
>
> It seems (from the ChangeLog entries for `mailcap-mime-data') that
> most entries are quite old.

mailcap.el is originally from w3 -- I think those entries were already
there when it was imported to Gnus.

> (Just a thought...)  We could split the data as follows:
> - defcustom mailcap-mime-data-internal (Lisp, PGP, message/* and other
>   internal stuff?)
> - defvar mailcap-mime-data-external (build this from mailcap files)
> - defvar mailcap-mime-data-external-fallback
>
> The default should be mailcap-mime-data = mailcap-mime-data-internal +
> mailcap-mime-data-external.  The user should be able to add the
> fallback entries `mailcap-mime-data-external-fallback' with, say
> (mailcap-add-fallback).

I'm not sure I get the purpose of the fallback entries.  What is the
difference between `mailcap-add' and `mailcap-add-fallback'?

Re: Disable mailcap support

[Reiner Steib]

On Fri, Oct 03 2003, Jesper Harder wrote:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>> (Just a thought...)  We could split the data as follows:
>> - defcustom mailcap-mime-data-internal (Lisp, PGP, message/* and other
>>   internal stuff?)
>> - defvar mailcap-mime-data-external (build this from mailcap files)
>> - defvar mailcap-mime-data-external-fallback
>>
>> The default should be mailcap-mime-data = mailcap-mime-data-internal +
>> mailcap-mime-data-external.  The user should be able to add the
>> fallback entries `mailcap-mime-data-external-fallback' with, say
>> (mailcap-add-fallback).
>
> I'm not sure I get the purpose of the fallback entries.  What is the
> difference between `mailcap-add' and `mailcap-add-fallback'?

If we do the suggested splitting (see above), IMHO we should offer a
simple way for the user (or other lisp programs) to add the external
entries (those now defined by `mailcap.el') to `mailcap-mime-data'.  A
function `mailcap-add-fallback' (maybe a better name would be
`mailcap-add-fallback-entries'?) would do this, preferring the entries
from mailcap files and from the defcustom'ed variable.

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

Re: Disable mailcap support

[Lars Magne Ingebrigtsen]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> (Just a thought...)  We could split the data as follows:
> - defcustom mailcap-mime-data-internal (Lisp, PGP, message/* and other
>   internal stuff?)
> - defvar mailcap-mime-data-external (build this from mailcap files)
> - defvar mailcap-mime-data-external-fallback

Sounds ok, but I don't really understand the need.

> The default should be mailcap-mime-data = mailcap-mime-data-internal +
> mailcap-mime-data-external.  The user should be able to add the
> fallback entries `mailcap-mime-data-external-fallback' with, say
> (mailcap-add-fallback).

The point of the fall-backs is that Gnus should just work.  If
somebody sent you a jpeg, you should be able to view it without
having to do anything in particular.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen