Image mode

Image mode

[Juri Linkov]

I'm very disappointed by the recent changes related to image display.
Due to paranoid fears, a good feature was deteriorated to an unusable state.
Can someone name any other major program were viewing images is
the same big pain for users as is now in Emacs!

Let's restore this feature back to the reasonable state.  This is simple:
before visiting an image file, the user sees its extension and by the
extension can decide whether to display the image or not.  There is
no need to require from the user typing more keys to do what the user
already decided to do.

A different case is image autodetection.  When the image file has an
extension unusual for image files or has no extension at all, then it
would be a (possibly bad) surprise for the user to see it displayed as
an image.  I agree that there should be an option that by default before
displaying the image from files with non-image extensions should either
ask for confirmation before visiting such file in image-mode, or (better)
visit the file just in image-minor-mode with more explanations shown
in the echo area.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Image mode

[Juanma Barranquero]

On 2/4/07, Juri Linkov <juri@jurta.org> wrote:

> Due to paranoid fears, a good feature was deteriorated to an unusable state.

Yes, you're right, if you mean that adding this to .emacs is an almost
insurmountable burden:

 (put 'image-toggle-display 'disabled nil)
 (setcdr (rassq 'image-mode-maybe magic-mode-alist)
         'image-mode)

                    /L/e/k/t/u

Re: Image mode

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/4/07, Juri Linkov <juri@jurta.org> wrote:
> 
> > Due to paranoid fears, a good feature was deteriorated to an unusable state.
> 
> Yes, you're right, if you mean that adding this to .emacs is an almost
> insurmountable burden:
> 
>  (put 'image-toggle-display 'disabled nil)
>  (setcdr (rassq 'image-mode-maybe magic-mode-alist)
>          'image-mode)

After some thought, I also think that the recent changes are an
overreaction.  After all, any program that displays images is
susceptible to the hypothetical "image-based viruses" that this change
is supposed to protect against, but you don't see anyone else issuing
big warnings into their programs.  Imagine opening up firefox, and
trying to view a webpage with images, only to be prompted each time
about whether or not to display each image.

At the very least, we should remove the 'disabled tag from
image-toggle-display.

Re: Image mode

[Juanma Barranquero]

On 04 Feb 2007 20:25:41 -0500, Chong Yidong <cyd@mit.edu> wrote:

> At the very least, we should remove the 'disabled tag from
> image-toggle-display.

Completely fine by me.

                    /L/e/k/t/u

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Juanma Barranquero <lekktu@gmail.com> wrote:

> Completely fine by me.

On second thought, no, it's not fine by me.

If you re-enable `image-toggle-display', having the images *not* shown
by default is just an inconvenience: the user's gonna do C-c C-c and
wonder why are we making things hard for him. There's no security
protection at all, because the user won't be aware there's a security
risk.

So, if you want to re-enable it, let's scrap the whole last month of
image changes and start rethinking it all: whether we want content
auto-detection for images, how to warn the user of the possible risks,
allowing easy customization for people that already understand the
issues, etc.

Rewriting is good sometimes. And it shouldn't take long.

I'm serious. It's better to delay Emacs 22 a week or two that release
a partial solution no one is happy with.

                    /L/e/k/t/u

Re: Image mode

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/5/07, Juanma Barranquero <lekktu@gmail.com> wrote:
>
>> Completely fine by me.
>
> On second thought, no, it's not fine by me.
>
> If you re-enable `image-toggle-display', having the images *not* shown
> by default is just an inconvenience: the user's gonna do C-c C-c and
> wonder why are we making things hard for him. There's no security
> protection at all, because the user won't be aware there's a security
> risk.
>
> So, if you want to re-enable it, let's scrap the whole last month of
> image changes and start rethinking it all: whether we want content
> auto-detection for images, how to warn the user of the possible risks,
> allowing easy customization for people that already understand the
> issues, etc.

Content auto-detection in connection with an image minor mode starting
in "on" state if the file name extension matches the recognized
content type, starting in "off" state with a notice

    Type C-c C-c to view as detected image type "JPG"

if it doesn't.

-- 
David Kastrup

Re: Image mode

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Content auto-detection in connection with an image minor mode
                                                     ^major
> starting in "on" state if the file name extension matches the
> recognized content type, starting in "off" state

and likely in a minor mode

> with a notice
>
>     Type C-c C-c to view as detected image type "JPG"
>
> if it doesn't.

-- 
David Kastrup

Re: Image mode

[Juanma Barranquero]

On 2/5/07, David Kastrup <dak@gnu.org> wrote:

> Content auto-detection in connection with an image minor mode starting
> in "on" state if the file name extension matches the recognized
> content type, starting in "off" state with a notice
>
>     Type C-c C-c to view as detected image type "JPG"
>
> if it doesn't.

Seems like a good plan.

                    /L/e/k/t/u

Re: Image mode

[Richard Stallman]

    > At the very least, we should remove the 'disabled tag from
    > image-toggle-display.

    Completely fine by me.

I never liked that idea.  Please delete the `disabled' tag.

Re: Image mode

[Juanma Barranquero]

On 2/6/07, Richard Stallman <rms@gnu.org> wrote:

> I never liked that idea.  Please delete the `disabled' tag.

Let's wait for the dust to settle, please.

                    /L/e/k/t/u

RE: Image mode

[Drew Adams]

Everyone's having such fun ;-). Just to stir the waters a little more...

1. We might want to consider a binary option that if non-nil would ask you
if you want to rename an image-file's suffix when Emacs determines the file
to be of a certain image type but the current suffix is non-standard for
that type. This is the behavior of some image-display applications, such as
IrfanView.

IOW, if an option `ask-to-rename-image-file-suffix-flag' is non-nil (the
default value, IMO), and if you open a file named foo.gif and it is really a
JPEG file (not that uncommon), Emacs asks you if you want to rename it to
foo.jpg (or perhaps to .jpeg).


2. A variant (better, IMO): Instead of a binary flag, use an alist
`ask-to-rename-image-file-suffixes' to define the acceptable suffixes for
each file type and indicate whether you want to be asked about renaming. The
alist entries would be (TYPE . SUFFIXES), where:

- TYPE would be a conventional symbol naming the file type - e.g. `jpeg' for
JPEG files.

- SUFFIXES would be a list of acceptable suffixes (strings) for files of
type TYPE. nil mean that all suffixes are acceptable for TYPE (so you are
not asked about files of type TYPE).

When SUFFIXES is non-nil, whenever you attempt to open (e.g. display) a file
that 1) Emacs determines is of type TYPE and 2) has a suffix that is not in
SUFFIXES, you are asked if you want to rename the suffix to (car SUFFIXES).

The question could be posed in such a way that you could reply `y' to rename
the suffix, `n' to leave the suffix alone this time, or `!' to leave the
suffix alone and inhibit future such questions for files of that type (the
updated option value would be saved). Or `a' to get the effect of `!' for
all image-file types.

Users who don't want to be bothered by such questions can customize the
option, answer `!' for individual file types, or answer `a' to never see a
question again.

`a' would set the value to nil, which would mean to never ask a question
about any image-file types. IOW, nil is the same as an alist whose entries
all have empty values (keys only).

The default value of the option would be an alist of all supported
image-file types and the conventional (usual) suffixes. It could be
platform-dependent, but probably wouldn't need to be.


3. Variant of the variant: Let the alist, `image-file-suffixes', do
double-duty. If there is an entry for a given file type, then Emacs should
try to determine the file type without regard to the current suffix. No
entry means do not check - rely on the suffix. So, the alist ((jpeg) (gif
"gif" "GIF")) would check both JPEG and GIF files, but would ask you about
renaming an incorrect suffix only for a GIF file (no rename question for
JPEG files). It would not check PNG files at all (that is, Emacs would trust
a "png" suffix, without checking the file contents).

Note that the suffixes could also be used to deal with case-sensitivity. An
entry of (gif "gif") would prompt you to rename a file named foo.GIF, but an
entry of (gif "gif" "GIF") would not. Even on a case-insensitive operating
system, you might want to ensure that all of your image files had, say,
lower-case suffixes (e.g. for use on a different platform). This wouldn't be
the way to go about renaming zillions of files, but it might be handy to
catch the occasional straggler.


4. Variant of the variant's variant: Reverse things, using t instead of nil
to indicate that all suffixes are permitted, and using the absense of an
entry of a particular type to mean that Emacs should never open files of
that type. IOW, above, with ((jpeg) (gif "gif" "GIF")), Emacs would always
open a file foo.png without checking its content, but in this variant, Emacs
would never open it - it would open only JPEG files (checking their content
but not asking about renaming) and GIF files (checking content and asking).
A value of ((jpeg) (gif "gif" "GIF") (png t)) would mean to a) do as before
for JPEG and GIF, b) rely upon the suffix for a PNG file, and refuse to open
a TIFF file.


5. Variant of whichever variant: Associate "Open", "Edit" etc. action
functions with image files of given types, by allowing alist entries to have
values that include pairs such as `edit my-editor'. E.g. ((jpeg (edit
my-image-editor) (open my-image-opener)) (gif "gif" "GIF" (edit
my-gif-editor)) (png (open my-image-opener) t)). If a file type doesn't have
an `open' action then use the default opener, etc., but if it has a null
`open' etc. action, then refuse to open etc. it - e.g. (png (open) t). The
action functions would be Emacs functions, but they might call upon external
programs (as async processes).


... Are we having fun yet?  Is the release having fun yet?

Re: Image mode

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> Everyone's having such fun ;-). Just to stir the waters a little more...

The options you give don't seem like an improvement.

-- 
David Kastrup

Re: Image mode

[Slawomir Nowaczyk]

On Mon, 05 Feb 2007 17:37:05 -0800
Drew Adams <drew.adams@oracle.com> wrote:

#> Everyone's having such fun ;-). Just to stir the waters a little more...

I think you have made a tactical mistake starting your email from
variant 1. The auto-renaming stuff just isn't really related to the
topic being discussed, I think.

I like some of your other ideas, but they are kind of lost in the noise,
I am afraid.

Just my 0.02 SEK

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

There are two rules for success in life: 1. Don't tell people everything you know.

Re: Image mode

[Richard Stallman]

      Imagine opening up firefox, and
    trying to view a webpage with images, only to be prompted each time
    about whether or not to display each image.

That is an interesting point.  Is it safe for firefox, and for eog or
qiv, to display a file without checking it?  If so, why in practice is
it safe?

The answer can't be "Because people check every JPG file before they
try to display it using eog or qiv or firefox."  I don't -- I would
not know how.  And I am sure most other users would not know how to
check.

So what is it in practice that prevents this from being a common way
for viruses to be introduced?

Re: Image mode

[Lennart Borgman (gmail)]

Richard Stallman wrote:

> That is an interesting point.  Is it safe for firefox, and for eog or
> qiv, to display a file without checking it?  If so, why in practice is
> it safe?
> 
> The answer can't be "Because people check every JPG file before they
> try to display it using eog or qiv or firefox."  I don't -- I would
> not know how.  And I am sure most other users would not know how to
> check.
> 
> So what is it in practice that prevents this from being a common way
> for viruses to be introduced?


That the image libraries are updated. Firefox updates itself or tells 
the user push a button to update Firefox whenever the authors of Firefox 
finds and fixes a security bug.

Re: Image mode

[Chong Yidong]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Richard Stallman wrote:
>
>> That is an interesting point.  Is it safe for firefox, and for eog or
>> qiv, to display a file without checking it?  If so, why in practice is
>> it safe?
>>
>> The answer can't be "Because people check every JPG file before they
>> try to display it using eog or qiv or firefox."  I don't -- I would
>> not know how.  And I am sure most other users would not know how to
>> check.
>>
>> So what is it in practice that prevents this from being a common way
>> for viruses to be introduced?
>
> That the image libraries are updated. Firefox updates itself or tells
> the user push a button to update Firefox whenever the authors of
> Firefox finds and fixes a security bug.

This may be true on Windows (I wouldn't know), but on GNU/Linux
systems, firefox relies on the same shared image libraries as everyone
else, and those are updated when the user updates the system
libraries; it is not initiated by Firefox.

The consensus seems to be that the way to handle the (hypothetical)
risk of security holes due to image library bugs is to patch the image
libraries if such bugs are found, NOT to hobble image display in
programs that use them.

As to why viruses haven't been very successful in propagating in this
way, I guess it's simply too difficult and impractical.  If the bug in
question is a buffer overrun in the image library, each exploit
probably needs to be targeted at particular applications using the
library, and there are much, MUCH easier targets than Emacs out there.

So I doubt we need to lose any sleep over this.

Re: Image mode

[Richard Stallman]

    The consensus seems to be that the way to handle the (hypothetical)
    risk of security holes due to image library bugs is to patch the image
    libraries if such bugs are found, NOT to hobble image display in
    programs that use them.

Can you say where you've seen this concensus affirmed?
Who is it a consensus among?  I want to get some idea of
how much we can trust their judgment.

Re: Image mode

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     The consensus seems to be that the way to handle the (hypothetical)
>     risk of security holes due to image library bugs is to patch the image
>     libraries if such bugs are found, NOT to hobble image display in
>     programs that use them.
>
> Can you say where you've seen this concensus affirmed?
> Who is it a consensus among?  I want to get some idea of
> how much we can trust their judgment.

It is an implicit conclusion, drawn from the fact that no other
graphical program prompts users before displaying images.

Security conscious (or paranoid) users can easily disable image
support in Emacs, so what's the problem?

Re: Image mode

[Slawomir Nowaczyk]

On Tue, 06 Feb 2007 18:41:07 -0500
Chong Yidong <cyd@stupidchicken.com> wrote:

#> Richard Stallman <rms@gnu.org> writes:
#> 
#> >     The consensus seems to be that the way to handle the (hypothetical)
#> >     risk of security holes due to image library bugs is to patch the image
#> >     libraries if such bugs are found, NOT to hobble image display in
#> >     programs that use them.
#> >
#> > Can you say where you've seen this concensus affirmed?
#> > Who is it a consensus among?  I want to get some idea of
#> > how much we can trust their judgment.
#> 
#> It is an implicit conclusion, drawn from the fact that no other
#> graphical program prompts users before displaying images.

"No other" is an overstatement, I suppose, since my email client does
not display attached images by itself. I have just tested, however, with
Opera mailer and -- to my surprise -- it did just that...

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

A few weeks of developing and testing can save a whole
afternoon in the library.

Re: Image mode

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/4/07, Juri Linkov <juri@jurta.org> wrote:
>
>> Due to paranoid fears, a good feature was deteriorated to an unusable state.
>
> Yes, you're right, if you mean that adding this to .emacs is an almost
> insurmountable burden:
>
> (put 'image-toggle-display 'disabled nil)
> (setcdr (rassq 'image-mode-maybe magic-mode-alist)
>         'image-mode)

Actually, it is.  The people most interested in painless image display
will be completely unable to come up with something like that.  The
first line is not so much of a problem, since it is entered as a
consequence of the "disabled" dialog by Emacs.  But the second?

-- 
David Kastrup

Re: Image mode

[Juanma Barranquero]

On 2/5/07, David Kastrup <dak@gnu.org> wrote:

> But the second?

Is in fact, irrelevant. I put in in my example to show how to revert
to a few weeks back, but having `image-mode-maybe' or `image-mode' in
`magic-mode-alist' is not going to make a difference (except that the
image will be in major or minor image mode): you still have to do C-c
C-c to see the image.

                    /L/e/k/t/u

Re: Image mode

[Chong Yidong]

I would like to present a concrete proposal based on the discussion
over the last couple of days.

Firstly, turn image autodetection off for xpm and xbm.  The reason for
this is that these are text-based image formats that will be handled
differently from binary images (see below).  An additional reason is
that C header files easily match the header-regexp for xbm, so the
main distinguishing feature of an xbm image is its filename, which
makes autodetection pointless.

Secondly, make autodetected images call image-mode instead of
image-mode-maybe, since only binary image formats are autodetected.

Thirdly, make the function image-type-auto-detected-p scan
auto-mode-alist for a non-image-mode match, and returns nil if one is
found.

Forthly, associate xpm and xbm files with image-mode-maybe in
auto-mode-alist; this will be the only use of image-mode-maybe.
image-mode-maybe scans auto-mode-alist for a non-image major mode,
turns on that mode, and turns on image-minor-mode.

The result is that binary image files are displayed in image-mode iff
their file contents are autodetected and their filenames do not
indicate a non-image mode.  This addresses the issue raised by several
people that a file named foo.c should never be opened as an image.
Binary image files are never displayed in image-minor-mode.
Text-based image files (xpm and xbm) are only detected by their
filename, and are opened in (in this case) C mode plus
image-minor-mode.

Finally, the `disabled' tag for image-toggle-display is removed, and
image-mode goes back to showing the image by default.

Any comments?

*** emacs/lisp/files.el.~1.882.~	2007-02-05 12:05:37.000000000 -0500
--- emacs/lisp/files.el	2007-02-06 20:27:53.000000000 -0500
***************
*** 2127,2133 ****
  associated with that interpreter in `interpreter-mode-alist'.")
  
  (defvar magic-mode-alist
!   `((image-type-auto-detected-p . image-mode-maybe)
      ;; The < comes before the groups (but the first) to reduce backtracking.
      ;; TODO: UTF-16 <?xml may be preceded by a BOM 0xff 0xfe or 0xfe 0xff.
      ;; We use [ \t\n] instead of `\\s ' to make regex overflow less likely.
--- 2127,2133 ----
  associated with that interpreter in `interpreter-mode-alist'.")
  
  (defvar magic-mode-alist
!   `((image-type-auto-detected-p . image-mode)
      ;; The < comes before the groups (but the first) to reduce backtracking.
      ;; TODO: UTF-16 <?xml may be preceded by a BOM 0xff 0xfe or 0xfe 0xff.
      ;; We use [ \t\n] instead of `\\s ' to make regex overflow less likely.
*** emacs/lisp/image.el.~1.69.~	2007-01-28 10:49:26.000000000 -0500
--- emacs/lisp/image.el	2007-02-07 14:05:28.000000000 -0500
***************
*** 67,77 ****
  
  (defvar image-type-auto-detectable
    '((pbm . t)
!     (xbm . t)
      (bmp . maybe)
      (gif . maybe)
      (png . maybe)
!     (xpm . maybe)
      (jpeg . maybe)
      (tiff . maybe)
      (postscript . nil))
--- 67,77 ----
  
  (defvar image-type-auto-detectable
    '((pbm . t)
!     (xbm . nil)
      (bmp . maybe)
      (gif . maybe)
      (png . maybe)
!     (xpm . nil)
      (jpeg . maybe)
      (tiff . maybe)
      (postscript . nil))
***************
*** 340,354 ****
  ;;;###autoload
  (defun image-type-auto-detected-p ()
    "Return t iff the current buffer contains an auto-detectable image.
! Whether image types are auto-detectable or not depends on the setting
! of the variable `image-type-auto-detectable'.
  
! This function is intended to be used from `magic-mode-alist' (which see)."
    (let* ((type (image-type-from-buffer))
  	 (auto (and type (cdr (assq type image-type-auto-detectable)))))
      (and auto
! 	 (or (eq auto t)
! 	     (image-type-available-p type)))))
  
  
  ;;;###autoload
--- 340,370 ----
  ;;;###autoload
  (defun image-type-auto-detected-p ()
    "Return t iff the current buffer contains an auto-detectable image.
! This function is intended to be used from `magic-mode-alist' (which see).
  
! First, compare the first few bytes of the buffer with
! `image-type-header-regexps'.  If an appropriate image type is
! found, consult the variable `image-type-auto-detectable' to see
! if it can be autodetected.  Finally, if `buffer-file-name' is
! non-nil, check if it matches another major mode in
! `auto-mode-alist' apart from `image-mode'; if there is another
! match, the autodetection is considered to have failed.  If all
! the preceding steps succeeded, return t."
    (let* ((type (image-type-from-buffer))
  	 (auto (and type (cdr (assq type image-type-auto-detectable)))))
      (and auto
! 	 (or (eq auto t) (image-type-available-p type))
! 	 (or (null buffer-file-name)
! 	     (not (assoc-default
! 		   buffer-file-name
! 		   (delq nil (mapcar 
! 			      (lambda (elt)
! 				(unless (memq (or (car-safe (cdr elt))
! 						  (cdr elt))
! 					      '(image-mode image-mode-maybe))
! 				  elt))
! 			      auto-mode-alist))
! 		   'string-match))))))
  
  
  ;;;###autoload
*** emacs/lisp/image-mode.el.~1.20.~	2007-02-02 20:00:19.000000000 -0500
--- emacs/lisp/image-mode.el	2007-02-07 13:53:58.000000000 -0500
***************
*** 60,65 ****
--- 60,71 ----
    (setq major-mode 'image-mode)
    (use-local-map image-mode-map)
    (add-hook 'change-major-mode-hook 'image-toggle-display-text nil t)
+   (if (and (display-images-p)
+ 	   (not (get-text-property (point-min) 'display)))
+       (image-toggle-display)
+     ;; Set next vars when image is already displayed but local
+     ;; variables were cleared by kill-all-local-variables
+     (setq cursor-type nil truncate-lines t))
    (run-mode-hooks 'image-mode-hook)
    (if (display-images-p)
        (message "%s" (concat
***************
*** 174,189 ****
        (if (called-interactively-p)
  	  (message "Repeat this command to go back to displaying the file as text")))))
  
- ;; Don't override the setting from .emacs.
- ;;;###autoload (put 'image-toggle-display 'disabled t)
- 
- (if (get 'image-toggle-display 'disabled)
-     (put 'image-toggle-display 'disabled "\
- 
- Warning: Displaying images in Emacs could be a security risk.
- Please ensure that you are using up-to-date image libraries
- and that the images being displayed come from a trusted source."))
- 
  (provide 'image-mode)
  
  ;; arch-tag: b5b2b7e6-26a7-4b79-96e3-1546b5c4c6cb
--- 180,185 ----

Re: Image mode

[Stuart D. Herring]

I like it, I think; it seems to cover everything, although the name
`image-mode-maybe' is now a bit odd.  However, one minor suggestion:

> Thirdly, make the function image-type-auto-detected-p scan
> auto-mode-alist for a non-image-mode match, and returns nil if one is
> found.

This should return nil unless auto-mode-alist suggests image mode, not
just nil if it suggests something else.  (The difference is files that
would get Fundamental mode.)  Even better would be to check that the
filename implies the -same- kind of image as the content, but this would
be slightly more involved, since auto-mode-alist doesn't store that
information.  The ease with which nil was returned could of course be
controlled by user options and/or let-binding auto-mode-alist (for
specialized things like thumbnails).

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Image mode

[Chong Yidong]

"Stuart D. Herring" <herring@lanl.gov> writes:

>> Thirdly, make the function image-type-auto-detected-p scan
>> auto-mode-alist for a non-image-mode match, and returns nil if one is
>> found.
>
> This should return nil unless auto-mode-alist suggests image mode, not
> just nil if it suggests something else.

No, this would mean that files with extension .JPG will not be opened
in image mode.  That was the original complaint that started this
thread :-P

Re: Image mode

[Stefan Monnier]

>>> Thirdly, make the function image-type-auto-detected-p scan
>>> auto-mode-alist for a non-image-mode match, and returns nil if one is
>>> found.
>> 
>> This should return nil unless auto-mode-alist suggests image mode, not
>> just nil if it suggests something else.

> No, this would mean that files with extension .JPG will not be opened
> in image mode.  That was the original complaint that started this
> thread :-P

So set auto-mode-case-fold to t and we're set ;-)


        Stefan

Re: Image mode

[Stuart D. Herring]

>>> Thirdly, make the function image-type-auto-detected-p scan
>>> auto-mode-alist for a non-image-mode match, and returns nil if one is
>>> found.
>>
>> This should return nil unless auto-mode-alist suggests image mode, not
>> just nil if it suggests something else.
>
> No, this would mean that files with extension .JPG will not be opened
> in image mode.  That was the original complaint that started this
> thread :-P

Then have it (with `let') examine auto-mode-alist case-insensitively? 
Your mechanism has the advantage of not being -part of- auto-mode-alist
and friends, but rather merely using them, and .Z is surely irrelevant
here.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Image mode

[Stefan Monnier]

> Then have it (with `let') examine auto-mode-alist case-insensitively? 
> Your mechanism has the advantage of not being -part of- auto-mode-alist
> and friends, but rather merely using them, and .Z is surely irrelevant
> here.

.Z is also irrelevant to auto-mode-case-fold, since it only ignores case
after a first case-sensitive traversal (i.e. it only ignores it if it
doesn't matter).


        Stefan

Re: Image mode

[Jason Rumney]

Stuart D. Herring wrote:
>> Thirdly, make the function image-type-auto-detected-p scan
>> auto-mode-alist for a non-image-mode match, and returns nil if one is
>> found.
>>     
>
> This should return nil unless auto-mode-alist suggests image mode

That is pointless. We might as well remove image-mode from magic-mode-alist.

Re: Image mode

[Stefan Monnier]

>>> Thirdly, make the function image-type-auto-detected-p scan
>>> auto-mode-alist for a non-image-mode match, and returns nil if one is
>>> found.
>> 
>> This should return nil unless auto-mode-alist suggests image mode

> That is pointless. We might as well remove image-mode from magic-mode-alist.

I thought it was the beauty of his proposal.  Yes, let's remove it from
magic-mode-alist.


        Stefan

Re: Image mode

[Stuart D. Herring]

>>>> Thirdly, make the function image-type-auto-detected-p scan
>>>> auto-mode-alist for a non-image-mode match, and returns nil if one is
>>>> found.
>>>
>>> This should return nil unless auto-mode-alist suggests image mode
>
>> That is pointless. We might as well remove image-mode from
>> magic-mode-alist.
>
> I thought it was the beauty of his proposal.  Yes, let's remove it from
> magic-mode-alist.

`image-mode' isn't on `magic-mode-alist'; `image-mode-maybe' is, and
although perhaps Stefan's stance of nixing it entirely is best, it seems
to me that the -maybe function belongs there.  Visiting foo.bar with a
JPEG header in it ought to load Image Minor Mode, provide the C-c C-c
message, and leave the buffer in Fundamental Mode, just as visiting foo.c
with the same contents should load, provide, and leave in C mode.  I think
(I hope) that's what the effect of Chong Yidong's proposal with my
suggestions, and I think that that's what `image-mode-maybe' is for.  (I
also suggested that visiting foo.png with the same contents should load in
image-mode without displaying, but that part is less important.)

Davis

PS - As far as implementing this, and dealing with the nasty hacks of
interacting magic and auto lists, wouldn't it work to change FUNCTION in
magic-mode-alist (if not in auto-mode-alist as well) into (FUNCTION .
CONTINUE), where CONTINUE non-nil would cause the rest of the list to be
scanned for further applicable functions (and would allow the processing
of other variables if no later line with CONTINUE nil matched)?  It seems
that such a generalization would be useful without being too heavy-handed;
for compatibility, for a while, a symbol (as most instances of FUNCTION
are) could be treated as (list SYMBOL).

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Image mode

[Chong Yidong]

"Stuart D. Herring" <herring@lanl.gov> writes:

> `image-mode' isn't on `magic-mode-alist'; `image-mode-maybe' is, and
> although perhaps Stefan's stance of nixing it entirely is best, it seems
> to me that the -maybe function belongs there.  Visiting foo.bar with a
> JPEG header in it ought to load Image Minor Mode, provide the C-c C-c
> message, and leave the buffer in Fundamental Mode, just as visiting foo.c
> with the same contents should load, provide, and leave in C mode.

Let's not go around in circles.

To re-iterate, the patch is meant to deal with the following issues
raised in this thread:

1. Several people have opinioned, sometimes vehemently, that when you
   open a file whose filename indicates that it is (e.g.) a text file,
   Emacs should never treat it as an image, even if its contents
   *look* like an image.  So this patch discards image autodetection
   results when there is a non-image mode match in auto-mode-alist.

   The only practical situation where image-minor-mode is useful are
   text-based images like xpm and xbm, and it has already been pointed
   out that autodetection (as opposed to filename detection) is
   useless for these since their contents match generic C header
   files.  So image-minor-mode should NOT be coupled with image
   autodetection.

2. That RMS wants .JPG files to be opened in image-mode through
   autodetection, rather than turning auto-mode-case-fold on by
   default.

Re: Image mode

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> I would like to present a concrete proposal based on the discussion
> over the last couple of days.

Thank you!

> Any comments?

Looks very good to me.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Image mode

[Juri Linkov]

> Thirdly, make the function image-type-auto-detected-p scan
> auto-mode-alist for a non-image-mode match, and returns nil if one is
> found.

I think your previous patch was better. `image-type-auto-detected-p'
should be a simple function whose sole purpose is to auto-detect the image
from the file content.  For users who don't care about negligibly small risks
of viewing any image, it would be easy to override the default element
`(image-type-auto-detected-p . image-mode-maybe)' in magic-mode-alist with
`(image-type-auto-detected-p . image-mode), thus always displaying images
auto-detected as images from the file content regardless of the file
extension (here I mean `image-type-auto-detected-p' is an original
implementation, not from your latest patch).

It is the function `image-mode-maybe' that should decide (ask the user
or use some option) whether display the file as an image, or put it
in `image-minor-mode', or something else (even the word `maybe' in
`image-mode-maybe' indicates the uncertainty about the outcome of this
function).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Image mode

[Jason Rumney]

Chong Yidong wrote:
> I would like to present a concrete proposal based on the discussion
> over the last couple of days.
>   
The only consequence of your proposal that I can see is that it removes 
the convenience of having an ambigous file start with image-minor-mode 
enabled, so the user has to do more work to display it.

Re: Image mode

[Chong Yidong]

Jason Rumney <jasonr@gnu.org> writes:

> Chong Yidong wrote:
> > I would like to present a concrete proposal based on the discussion
> > over the last couple of days.
> >
> The only consequence of your proposal that I can see is that it
> removes the convenience of having an ambigous file start with
> image-minor-mode enabled, so the user has to do more work to display
> it.

As I (and several others) have argued, that is a dubious convenience.

Re: Image mode

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> A different case is image autodetection.  When the image file has an
> extension unusual for image files or has no extension at all, then it
> would be a (possibly bad) surprise for the user to see it displayed as
> an image.  I agree that there should be an option that by default before
> displaying the image from files with non-image extensions should either
> ask for confirmation before visiting such file in image-mode, or (better)
> visit the file just in image-minor-mode with more explanations shown
> in the echo area.

As Richard has argued, IF displaying an image can cause a security
risk, it doesn't matter whether or not that image was autodetected or
had the relevant file name.  So let's please not worry about this.

Many other programs that deal with images engage in image
autodetection by content, so the consensus in the software community
seems to be that the kind of risks we are worried about are not worth
the hassle of protecting against.  More precisely, if an image library
is susceptible in this way, it is the image library that should be
fixed.

As I mentioned in a preceding email, I think the recently-added
`disabled' tag for image-toggle-display should be removed.  I think we
can leave the behavior where you have to type C-c C-c to display an
image after entering image-mode; but we should provide an option (not
enabled by default) to display images automatically upon entering
image-mode, as before.

Re: Image mode

[Miles Bader]

Chong Yidong <cyd@MIT.EDU> writes:
> As I mentioned in a preceding email, I think the recently-added
> `disabled' tag for image-toggle-display should be removed.  I think we
> can leave the behavior where you have to type C-c C-c to display an
> image after entering image-mode; but we should provide an option (not
> enabled by default) to display images automatically upon entering
> image-mode, as before.

I agree.

-Miles

-- 
My books focus on timeless truths.  -- Donald Knuth

Re: Image mode

[Kim F. Storm]

Miles Bader <miles.bader@necel.com> writes:

> Chong Yidong <cyd@MIT.EDU> writes:
>> As I mentioned in a preceding email, I think the recently-added
>> `disabled' tag for image-toggle-display should be removed.  I think we
>> can leave the behavior where you have to type C-c C-c to display an
>> image after entering image-mode; but we should provide an option (not
>> enabled by default) to display images automatically upon entering
>> image-mode, as before.
>
> I agree.
>

Me too.

In fact, I find the current issue of image auto-detection pretty silly.

What we are trying to "fix" is when a user _ACTIVELY OPENS_ an image
file with C-x C-f ... and in 99.99% of the time, the user will know
perfectly what the file contains (after all, it is already installed
on his own machine -- or from some trusted source -- where he will 
really want to view the image).

In contrast, if someone sends me a JPEG image in an email, Gnus
will happily show it to me without asking (at least with the
settings I'm using).  So where's the protection in that case?

And so does Firefox - which happily shows images from sources which
are by definition _untrusted_!


IMO, let image files opened with C-x C-f be shown automatically as
they did until recently.  I don't even see a reason to be able to
disable it.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Image mode

[Lennart Borgman (gmail)]

Kim F. Storm wrote:

> IMO, let image files opened with C-x C-f be shown automatically as
> they did until recently.  I don't even see a reason to be able to
> disable it.

Agree. Protection must be about automatically opening unknown images.

But please remember that Emacs in contrast with Firefox currently lacks 
automatic updating of image libraries.

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> Agree. Protection must be about automatically opening unknown images.

What are "unknown images"?

                    /L/e/k/t/u

Re: Image mode

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/5/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
>
>> Agree. Protection must be about automatically opening unknown images.
>
> What are "unknown images"?

Files for which the user is likely surprised that they are image
files.  It seems like inappropriate file extensions (either those
suggesting a different major mode, or those suggesting nothing at all)
would be a good indicator.

-- 
David Kastrup

Re: Image mode

[Juanma Barranquero]

On 2/5/07, David Kastrup <dak@gnu.org> wrote:

> Files for which the user is likely surprised that they are image
> files.  It seems like inappropriate file extensions (either those
> suggesting a different major mode, or those suggesting nothing at all)
> would be a good indicator.

OK, but then we go back to the start: JPG, JPEG, TIF, TIFF, PNG, GIF,
XBM, etc. are also valid image extensions, not only their downcased
variants.

                    /L/e/k/t/u

Re: Image mode

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/5/07, David Kastrup <dak@gnu.org> wrote:
>
>> Files for which the user is likely surprised that they are image
>> files.  It seems like inappropriate file extensions (either those
>> suggesting a different major mode, or those suggesting nothing at all)
>> would be a good indicator.
>
> OK, but then we go back to the start: JPG, JPEG, TIF, TIFF, PNG, GIF,
> XBM, etc. are also valid image extensions, not only their downcased
> variants.

image-file-name-extensions could be matched independent of case.
Maybe this would even be a workable idea for auto-mode-alist (there
are actually rather few extensions, like ".Z", where there would be
some argument against it).

-- 
David Kastrup

Re: Image mode

[Juanma Barranquero]

On 2/5/07, David Kastrup <dak@gnu.org> wrote:

> Maybe this would even be a workable idea for auto-mode-alist (there
> are actually rather few extensions, like ".Z", where there would be
> some argument against it).

And now, we're FINALLY BACK TO THE START!! Congratulations!!

:) :)

Sorry, I couldn't resist.

This whole kerfuffle started like this: someone asks for Emacs to
recognize uppercase image extensions, some other developer talks about
doing that (generically) for all `auto-mode-alist', Richard says "No
way" (because it is not the correct thing to do), a bit of discussion,
I propose using content auto-detection, another user or developer
agrees because he has thumbnail images with no recognizable extension
(from his camera), more discussion about doing lower-case and then
case-folded passes over `auto-mode-alist', Richard says "No way" a few
more times, image auto-detection gets implemented, then security
concerns arise... and the rest is history.

(Of course, that's my abridged, and highly subjective, recollection
from the several threads where all this has been discussed; and I mean
*no disrespect at all* for anyone involved in the discussion.)

                    /L/e/k/t/u

Re: Image mode

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/5/07, David Kastrup <dak@gnu.org> wrote:
>
>> Maybe this would even be a workable idea for auto-mode-alist (there
>> are actually rather few extensions, like ".Z", where there would be
>> some argument against it).
>
> And now, we're FINALLY BACK TO THE START!! Congratulations!!

I said "maybe even".  Does not sound like the start.

> This whole kerfuffle started like this: someone asks for Emacs to
> recognize uppercase image extensions, some other developer talks
> about doing that (generically) for all `auto-mode-alist', Richard
> says "No way" (because it is not the correct thing to do), a bit of
> discussion, I propose using content auto-detection, another user or
> developer agrees because he has thumbnail images with no
> recognizable extension (from his camera), more discussion about
> doing lower-case and then case-folded passes over `auto-mode-alist',
> Richard says "No way" a few more times, image auto-detection gets
> implemented, then security concerns arise... and the rest is
> history.

So I have not followed all of the discussion.  Sue me.  Anyway, your
history does not list the details of using case folding just on
image-file-name-extensions.

Was that also discussed to some conclusion, or did it get lost among
the auto-mode-alist noise?

-- 
David Kastrup

Re: Image mode

[Juanma Barranquero]

On 2/5/07, David Kastrup <dak@gnu.org> wrote:

> I said "maybe even".  Does not sound like the start.

I was trying to inject a little humor in this thread, because,
frankly, otherwise the whole image recognition discussion is gonna
bore me dead. But we must do something, or Emacs 22 won't hit the
shelves till 2038, and then we will have to worry about the Y2038
effect before the release...

> So I have not followed all of the discussion.  Sue me.

Expect a letter from my law... oh, sorry, I forgot we europeans aren't
lawsuit-crazy.

>  Anyway, your
> history does not list the details of using case folding just on
> image-file-name-extensions.

I honestly don't remember whether that was discussed or not. It's a
good idea, though.

> Was that also discussed to some conclusion, or did it get lost among
> the auto-mode-alist noise?

Difficult to say. You'll have to search on the archives.

                    /L/e/k/t/u

Re: Image mode

[Stefan Monnier]

> And now, we're FINALLY BACK TO THE START!! Congratulations!!
> :) :)
> Sorry, I couldn't resist.

> This whole kerfuffle started like this: someone asks for Emacs to
> recognize uppercase image extensions, some other developer talks about
> doing that (generically) for all `auto-mode-alist', Richard says "No
> way" (because it is not the correct thing to do),

Yup.  This "no way" wasted us a lot of time already.  And it still hasn't
been justified.


        Stefan

Re: Image mode

[Richard Stallman]

    Files for which the user is likely surprised that they are image
    files.  It seems like inappropriate file extensions (either those
    suggesting a different major mode, or those suggesting nothing at all)
    would be a good indicator.

I didn't believe this before, and I don't believe it now.
There is no rational reason to assume that an extension of .jpg
means the file can't do harm.  Most users do NOT feel suspicious
of files on account of a name ending in .jpg.

If indeed it is safe to open images if and only if their extensions
say they are images, the reason would have to be something more subtle
than what people have said here so far.

Re: Image mode

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     Files for which the user is likely surprised that they are image
>     files.  It seems like inappropriate file extensions (either those
>     suggesting a different major mode, or those suggesting nothing at all)
>     would be a good indicator.
> 
> I didn't believe this before, and I don't believe it now.
> There is no rational reason to assume that an extension of .jpg
> means the file can't do harm.  Most users do NOT feel suspicious
> of files on account of a name ending in .jpg.
> 
> If indeed it is safe to open images if and only if their extensions
> say they are images, the reason would have to be something more subtle
> than what people have said here so far.

You can for example have heard that a new security bug was discovered in 
jpeg libraries. Then you would avoid opening jpeg images until this has 
been fixed.

In such a case it is important to know how your program will open the 
images. (Will the program use the jpeg libraries?)

Re: Image mode

[Richard Stallman]

    You can for example have heard that a new security bug was discovered in 
    jpeg libraries. Then you would avoid opening jpeg images until this has 
    been fixed.

This can happen, for some people -- but most users won't hear about
such things, and won't avoid viewing jpegs.  So we cannot expect
safety to be achieved that way.  For whatever that matters.

    In such a case it is important to know how your program will open the 
    images. (Will the program use the jpeg libraries?)

We can tell people that Emacs will use the jpeg libraries,
but most users won't draw any particular conclusions from that.
They will just think "ok" or "so what?"

Re: Image mode

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Files for which the user is likely surprised that they are image
>     files.  It seems like inappropriate file extensions (either those
>     suggesting a different major mode, or those suggesting nothing at all)
>     would be a good indicator.
>
> I didn't believe this before, and I don't believe it now.  There is
> no rational reason to assume that an extension of .jpg means the
> file can't do harm.  Most users do NOT feel suspicious of files on
> account of a name ending in .jpg.

There are two things being confounded here:

a) letting a user open a potentially dangerous image as an image
unwittingly.
b) letting the user open a potentially dangerous image at all.

You argue against option b) here.  The solution to that is obvious and
easy: compile Emacs without image support.  This is the only way in
which Emacs will never let the user open a potentially damaging image.

Now if we all agree that opening images at all should not be
prevented, but should be at the user's discretion, we get back to
preventing case a).  It is a reasonable assumption that a user opening
a file with a well-known image extension is not going to be surprised
to have it displayed as an image.

Since Emacs does not go around opening files without the user telling
it, this will put the choice of whether to open files in image mode in
the hands of the user.

In other words: our list of image extensions is not so much important
for what Emacs will recognize as an image file, but rather for what a
user will recognize (and accept) as an image file.

For that reason, I also think it reasonable to do the match for image
extensions case-insensitive.

> If indeed it is safe to open images if and only if their extensions
> say they are images, the reason would have to be something more
> subtle than what people have said here so far.

It is not "safe".  That is a straw man.  It will _never_ be safe.  But
it does not happen without the user expecting it.

-- 
David Kastrup

Re: Image mode

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On 2/5/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
> 
>> Agree. Protection must be about automatically opening unknown images.
> 
> What are "unknown images"?


Sorry, I was trying to refer to the previous discussion. Opening an 
image with C-x C-f seems quite ok to me, at least if I am doing that 
myself ;-)

If I were using gnus and there were an image attachment then I would 
prefer to open that myself. It should not be opened automatically when I 
read a message (unless I have set an option saying it is ok).

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> Opening an
> image with C-x C-f seems quite ok to me, at least if I am doing that
> myself ;-)

Even if the image lacks a recognized image file extension? I.e., do
you think that opening a .c file containing a JPEG should

 1) Start in image-mode and display the image
 2) Start in C mode, image-minor-mode and display the image
 3) Start in image-mode and not display the image
 4) Start in C mode, image-minor-mode and not display the image
 5) Start in fundamental mode, image-minor-mode and display the image
 6) Start in fundamental mode, image-minor-mode and not display the image
 7) Start in C mode and bypass image mode (major and minor)
 8) Start in fundamental mode and bypass all mode detection

                    /L/e/k/t/u

Re: Image mode

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/5/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
>
>> Opening an
>> image with C-x C-f seems quite ok to me, at least if I am doing that
>> myself ;-)
>
> Even if the image lacks a recognized image file extension? I.e., do
> you think that opening a .c file containing a JPEG should
>
> 1) Start in image-mode and display the image
> 2) Start in C mode, image-minor-mode and display the image
> 3) Start in image-mode and not display the image
> 4) Start in C mode, image-minor-mode and not display the image
> 5) Start in fundamental mode, image-minor-mode and display the image
> 6) Start in fundamental mode, image-minor-mode and not display the image
> 7) Start in C mode and bypass image mode (major and minor)
> 8) Start in fundamental mode and bypass all mode detection

I'd pick 4.

-- 
David Kastrup

Re: Image mode

[Mathias Dahl]

> Even if the image lacks a recognized image file extension? I.e., do
> you think that opening a .c file containing a JPEG should
>
>  1) Start in image-mode and display the image
>  2) Start in C mode, image-minor-mode and display the image
>  3) Start in image-mode and not display the image
>  4) Start in C mode, image-minor-mode and not display the image
>  5) Start in fundamental mode, image-minor-mode and display the image
>  6) Start in fundamental mode, image-minor-mode and not display the image
>  7) Start in C mode and bypass image mode (major and minor)
>  8) Start in fundamental mode and bypass all mode detection

What happened to this:

"The extension of file you are about to open suggests that it is a
text file, but the content seems to be an image. Do you want to open
it as an image?"

?

Or something similar.

My apologies if I haven't paid enough attention to this thread worthy
of a place in Guiness Book of Records.

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Mathias Dahl <mathias.dahl@gmail.com> wrote:

> What happened to this:
>
> "The extension of file you are about to open suggests that it is a
> text file, but the content seems to be an image. Do you want to open
> it as an image?"

What happened is that it required more code and no one offered to implement it.

                    /L/e/k/t/u

Re: Image mode

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/5/07, Mathias Dahl <mathias.dahl@gmail.com> wrote:
>
>> What happened to this:
>>
>> "The extension of file you are about to open suggests that it is a
>> text file, but the content seems to be an image. Do you want to open
>> it as an image?"
>
> What happened is that it required more code and no one offered to implement it.

How about this patch?

It brings up the prompt when the image autodetection clashes with
auto-mode-alist, and restores the old image-mode behavior for all
other cases.

*** emacs/lisp/image-mode.el.~1.20.~	2007-02-02 20:00:19.000000000 -0500
--- emacs/lisp/image-mode.el	2007-02-05 12:05:59.000000000 -0500
***************
*** 60,65 ****
--- 60,71 ----
    (setq major-mode 'image-mode)
    (use-local-map image-mode-map)
    (add-hook 'change-major-mode-hook 'image-toggle-display-text nil t)
+   (if (and (display-images-p)
+ 	   (not (get-text-property (point-min) 'display)))
+       (image-toggle-display)
+     ;; Set next vars when image is already displayed but local
+     ;; variables were cleared by kill-all-local-variables
+     (setq cursor-type nil truncate-lines t))
    (run-mode-hooks 'image-mode-hook)
    (if (display-images-p)
        (message "%s" (concat
***************
*** 97,115 ****
  See commands `image-mode' and `image-minor-mode' for more
  information on these modes."
    (interactive)
!   (let* ((mode-alist
! 	  (delq nil (mapcar
! 		     (lambda (elt)
! 		       (unless (memq (or (car-safe (cdr elt)) (cdr elt))
! 				     '(image-mode image-mode-maybe))
! 			 elt))
! 		     auto-mode-alist))))
!     (if (assoc-default buffer-file-name mode-alist 'string-match)
! 	(let ((auto-mode-alist mode-alist)
! 	      (magic-mode-alist nil))
! 	  (set-auto-mode)
! 	  (image-minor-mode t))
!       (image-mode))))
  
  (defun image-toggle-display-text ()
    "Showing the text of the image file."
--- 103,135 ----
  See commands `image-mode' and `image-minor-mode' for more
  information on these modes."
    (interactive)
!   (if (and buffer-file-name (not noninteractive))
!       (let* ((mode-alist
! 	      (delq nil (mapcar
! 			 (lambda (elt)
! 			   (unless (memq (or (car-safe (cdr elt))
! 					     (cdr elt))
! 					 '(image-mode image-mode-maybe))
! 			     elt))
! 			 auto-mode-alist)))
! 	     match)
! 	(if (and (setq match (assoc-default buffer-file-name mode-alist
! 					    'string-match))
! 		 ;; Another major mode was found: prompt the user
! 		 (not (yes-or-no-p
! 		       (format
!   "The contents of the file %s indicate that it is a %s image file.
! However, it could also be opened in %s.
! Open %s as an image file? "
! 		         (file-name-nondirectory buffer-file-name)
! 			 (symbol-name (image-type-from-buffer))
! 			 (symbol-name match)
! 		         (file-name-nondirectory buffer-file-name)))))
! 	    (let ((auto-mode-alist mode-alist)
! 		  (magic-mode-alist nil))
! 	      (set-auto-mode))
! 	  (image-mode)))
!     (image-mode)))
  
  (defun image-toggle-display-text ()
    "Showing the text of the image file."
***************
*** 174,189 ****
        (if (called-interactively-p)
  	  (message "Repeat this command to go back to displaying the file as text")))))
  
- ;; Don't override the setting from .emacs.
- ;;;###autoload (put 'image-toggle-display 'disabled t)
- 
- (if (get 'image-toggle-display 'disabled)
-     (put 'image-toggle-display 'disabled "\
- 
- Warning: Displaying images in Emacs could be a security risk.
- Please ensure that you are using up-to-date image libraries
- and that the images being displayed come from a trusted source."))
- 
  (provide 'image-mode)
  
  ;; arch-tag: b5b2b7e6-26a7-4b79-96e3-1546b5c4c6cb
--- 194,199 ----

Re: Image mode

[Mathias Dahl]

> > What happened is that it required more code and no one offered to implement it.
>
> How about this patch?
>
> It brings up the prompt when the image autodetection clashes with
> auto-mode-alist, and restores the old image-mode behavior for all
> other cases.

I like it.

I took one of my by now infamous .thm files (which is really a JPEG
image) and tried to open it with `find-file'. Named with a .thm
extension Emacs displayed the image without warning me (I have nothing
in my `auto-mode-alist' that matches thm-files). Renamed as "muu.txt"
Emacs asked me:

 The contents of the file muu.txt indicate that it is a jpeg image file.
  However, it could also be opened in text-mode.
  Open muu.txt as an image file? (yes or no)

yes => displays file as an image
no => displays file as text

Works for me.

Re: Image mode

[Jason Rumney]

Chong Yidong wrote:
> How about this patch?
>   

I think we should take a step back and design this properly rather than 
introducing more patches.

Your proposed patch breaks the display of xbm and xpm files, since you 
are repurposing image-mode-maybe to solve this problem, rather than its 
original purpose of letting the user switch between the applicable 
major-mode and image display with C-c C-c.

Re: Image mode

[Chong Yidong]

Jason Rumney <jasonr@gnu.org> writes:

> Chong Yidong wrote:
>> How about this patch?
>>   
>
> I think we should take a step back and design this properly rather
> than introducing more patches.
>
> Your proposed patch breaks the display of xbm and xpm files, since you
> are repurposing image-mode-maybe to solve this problem, rather than
> its original purpose of letting the user switch between the applicable
> major-mode and image display with C-c C-c.

Indeed, xpm and xbm are special in that they can be treated as both C
files and images.  I think the solution is to handle them specially.

In its original form, image-mode-maybe, which applies to ALL
autodetected image files (not just xpm and xbm) tries to load the
image in a non-image major mode and turn on image-minor-mode.  This is
a mistake, because we are making the needs of a special case (xpm/xbm)
interfere with the more general situation (a file is either an image
or a non-image).

Clearly, the solution is to separate out the special case.  Let us
remove xpm/xbm detection from image-type-auto-detected-p, and add a
new entry to magic-mode-alist that specifically detects xpm/xbm
images, and turns on c-mode and image-minor-mode.  All other images
will be handled using my patch.

If people agree with this design, I can implement it quite easily.

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Chong Yidong <cyd@stupidchicken.com> wrote:

> Indeed, xpm and xbm are special in that they can be treated as both C
> files and images.

As it is Postscript. That's part of the reason
`image-type-auto-detected-p' and `image-type-auto-detectable' were
introduced.

> Let us
> remove xpm/xbm detection from image-type-auto-detected-p

That's just setting them to nil in `image-type-auto-detectable'.

Still...

> If people agree with this design, I can implement it quite easily.

...I really, knees-on-the-ground, wholeheartedly BEG we don't do more
accretion-patching without taking half a dozen steps back to gain some
perspective.

                    /L/e/k/t/u

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Juanma Barranquero <lekktu@gmail.com> wrote:

> As it is Postscript.

Obviously, not as C and an image, but as an image and code in a
programming language :(

                    /L/e/k/t/u

Re: Image mode

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> As it is Postscript. That's part of the reason
> `image-type-auto-detected-p' and `image-type-auto-detectable' were
> introduced.

As I argued, making this behavior applicable to all images is a
mistake.  Clearly, we should treat postscript, xpm, and xbm separately
from jpegs and pngs.

> ...I really, knees-on-the-ground, wholeheartedly BEG we don't do more
> accretion-patching without taking half a dozen steps back to gain some
> perspective.

No drama, please.  If you have a specific suggestion, feel free to
propose it.  My proposal is quite simple, if you actually consider it
instead of complaining about accretion:

- One function in magic-mode-alist autodetects image types that do not
  make sense to edit (jpgs, pngs, etc).  If the result is ambiguous
  (as determined by checking auto-mode-alist), prompt the user about
  whether to use image-mode or the non-image mode specified by
  auto-mode-alist.

- A second function autodetects image types that do make sense to edit
  (ps, xpm, xbm).  If autodetected, set up the editing mode and turn
  on image-minor-mode.

- Otherwise, use auto-mode-alist.

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Chong Yidong <cyd@stupidchicken.com> wrote:

> No drama, please.

Why? Are there rules against drama in the list which I'm not aware of?

> If you have a specific suggestion, feel free to
> propose it.

I've already done a very specific suggestion: remove and rethink. And
I'm not the only one (nor the first, I think) in suggesting it as a
good course of action.

> My proposal is quite simple, if you actually consider it

Did you use some kind of extra-sensory powers to know what did or
didn't I consider? Or do you deduce I didn't consider it just because
I don't agree with you?

> instead of complaining about accretion:

Why? What's wrong, *exactly*, with complaining about what I perceive
as a clear problem?

                    /L/e/k/t/u

Re: Image mode

[Stefan Monnier]

> I've already done a very specific suggestion: remove and rethink.  And I'm
> not the only one (nor the first, I think) in suggesting it as a good
> course of action.

Indeed, I wholeheartedly agree.


        Stefan

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Indeed, I wholeheartedly agree.

Thanks. But please be careful with your choice of adverbs, lest you
accidentally overstep into drama.

                    /L/e/k/t/u

Re: Image mode

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

>> If you have a specific suggestion, feel free to
>> propose it.
>
> I've already done a very specific suggestion: remove and rethink. And
> I'm not the only one (nor the first, I think) in suggesting it as a
> good course of action.

There is no need to remove; once we come up with a solution, we can
remove any unnecessary pieces of code.

As for rethinking, I have given my plan.  Do you also have a plan (as
opposed to a plan to make a plan)?

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Chong Yidong <cyd@stupidchicken.com> wrote:

> There is no need to remove; once we come up with a solution, we can
> remove any unnecessary pieces of code.

Talk about starting from scratch... Why don't you want to remove it?
What's the problem with re-adding the bits we do agree on?

> As for rethinking, I have given my plan.  Do you also have a plan (as
> opposed to a plan to make a plan)?

Yes: to seek an agreement. Perhaps you've missed the point that I
asked a specific question with eight possible answers, and the
results, at this moment, are: 4, 7, 9 (which wasn't on the menu, but
that's cool), and I would surely choose either 1 or 3. So you wanting
to add more code is not helping us to decide What Do We Want To Do*.

                    /L/e/k/t/u

* (I'm sorry if capitalized words seem like drama to you, BTW.)

Re: Image mode

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

>> As for rethinking, I have given my plan.  Do you also have a plan (as
>> opposed to a plan to make a plan)?
>
> Yes: to seek an agreement. Perhaps you've missed the point that I
> asked a specific question with eight possible answers, and the
> results, at this moment, are: 4, 7, 9 (which wasn't on the menu, but
> that's cool), and I would surely choose either 1 or 3.

And perhaps you've missed my answer to that: i.e., that trying to open
a file named foo.c, whose contents are jpeg data, should

9) ask the user whether he wants to open as an image or as a C file.

which was not in your list of options.

As far as I can tell, there are only two coherent schemes on the
table: (i) the one I have proposed, which involves making the effects
of image autodetection a little smarter; and (ii) removing image
autodetection through magic-mode-alist, possibly with the addition of
.JPG to auto-mode-alist.  If there is a third scheme that someone has
proposed, which I have missed, please point it out.

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Chong Yidong <cyd@stupidchicken.com> wrote:

> > Yes: to seek an agreement. Perhaps you've missed the point that I
> > asked a specific question with eight possible answers, and the
> > results, at this moment, are: 4, 7, 9 (which wasn't on the menu, but
> > that's cool), and I would surely choose either 1 or 3.
>
> And perhaps you've missed my answer to that: i.e., that trying to open
> a file named foo.c, whose contents are jpeg data, should
>
> 9) ask the user whether he wants to open as an image or as a C file.

Please, re-read my paragraph as you quoted it: "9 (which wasn't on the
menu [...]".

> If there is a third scheme that someone has
> proposed, which I have missed, please point it out.

I *don't* have to point it out. I want for us to take the time so
anyone can point a third, fourth or seventh alternative, or perhaps
choose one of the two you describe, but, why rush choosing?

                    /L/e/k/t/u

Re: Image mode

[Chong Yidong]

>> If there is a third scheme that someone has
>> proposed, which I have missed, please point it out.
>
> I *don't* have to point it out. I want for us to take the time so
> anyone can point a third, fourth or seventh alternative, or perhaps
> choose one of the two you describe, but, why rush choosing?

Then we are agreed.

So: can anyone provide an alternative?

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Chong Yidong <cyd@stupidchicken.com> wrote:

> So: can anyone provide an alternative?

I think the first step would be to summarize the existing
alternatives. I don't mean a terse description, I mean to explain the
interaction between auto-detection, the major and minor image modes
(and image-mode-maybe), auto-mode-alist, magic-mode-alist,
image-type-*-regexps, image-file-name-*, what to do with find-file vs.
find-file-noselect, how *each* known image type (know to Emacs, I
mean) is going to be treated, what customization options are we going
to provide (for example, I'd really like to deactivate all the
security stuff and just make Emacs open images by contents, not file
extension), etc.

Currently it is difficult to see how everything already implemented
interacts, and every patch (including, I think, the last you proposed)
has been shown to have unexpected and undesired consequences.
                    /L/e/k/t/u

Re: Image mode

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/5/07, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> So: can anyone provide an alternative?
>
> I think the first step would be to summarize the existing
> alternatives.

OK, here is my stab at this.

(First, let us recall that when choosing a major mode,
magic-mode-alist has precedence over auto-mode-alist.  The former
performs "autodetection", i.e. selecting the mode using the file
contents.  The latter performs what we will refer to as "filename
detection", i.e. selecting the mode using the filename.)

Here are three schemes.

Scheme 1: Image autodetection, with two classes of image types
   and user prompting

 - Handle image autodetection in two steps.
 - First, autodetect binary images (jpeg, png, gif, tiff).  If
   autodetected, check for a non-image mode in auto-mode-alist.  If no
   match is found, go ahead and open in image-mode.  If a match for a
   non-image mode is found, ask the user whether to open in
   image-mode, or in the mode specified in auto-mode-alist.
 - Second, autodetect text-based images (xpm, postscript, xbm).
   If autodetected, check for a non-image mode in auto-mode-alist.  If
   no match is found, open in image-mode (this should not happen).  If
   a match is found, open in the non-image major mode and
   image-minor-mode.
 - If autodetection fails, perform filename detection.

 - The (existing) option image-type-auto-detectable determines which
   image files can be autodetected.

 - Advantages: Seems to handle all known problematic cases.
   Text-based images are opened in foo-mode with image-minor-mode;
   images with funky file-names are opened in image-mode if no other
   suitable mode is found, or the user is prompted if there is an
   ambiguity.

 - Disadvantages: The behavior is complicated.  Also, prompting the
   user may not be straightforward for other uses of
   find-file-nonselect (are there any specific examples?).  Also,
   setting image-minor-mode is naughty: it violates the standard that
   Emacs does not automatically turn on minor-modes on for the user.

Scheme 2: Image autodetection with deference to auto-mode-alist for
   binary image files

 - As above, except that is a binary image is autodetected, and a
   match for a non-image mode is found, fall back on the non-image
   mode instead of prompting the user.

 - Advantages: Principle of least surprise.  A Jpeg file saved as
   foo.txt is handled as a text file; one saved as foo.JPG or foo.bar
   is handled as an image (since Emacs sees no other choice).
   Avoids possible difficulties with user prompting.

 - Disadvantages: As above, setting image-minor-mode is naughty.  If
   foo.c really IS a jpeg file, it might (?) be more correct to
   display it as a jpeg file; this doesn't do that.

Scheme 3: No image autodetection

 - Images are not autodetected.  Only auto-mode-alist is used.
 - In particular, XPM and XBM images are opened in C mode (see above).
 - The commonly-encountered .JPG extension should be recognized as an
   jpeg file, either by making auto-mode-case-fold default to t, or
   adding .JPG to auto-mode-alist.

 - Advantages: The behavior is simple.  As Stefan notes, few or no
   other programs auto-detect images as images using their content,
   and it may be safer to avoid surprising the user.

 - Disadvantages: Richard apparently dislikes auto-mode-case-fold
   (this may not be a theoretical disadvantage, but it is a practical
   one).  On the other hand, if we add .JPG to auto-mode-alist, we
   might as well add .PNG, .GIF, etc---which is ugly (though it may be
   the practical thing to do).

Personally, I think scheme 2 may be a good compromise.

Re: Image mode

[Juanma Barranquero]

On 2/6/07, Chong Yidong <cyd@stupidchicken.com> wrote:

> OK, here is my stab at this.

Thanks.

> Here are three schemes.

AFAICS, all schemes are abandoning the idea of protecting (or at least
warning) the user against potentially dangerous but correctly named
image files; is that so?

>    foo.c really IS a jpeg file, it might (?) be more correct to
>    display it as a jpeg file; this doesn't do that.

It'd be nice to be able to configure that.

> Personally, I think scheme 2 may be a good compromise.

I also like 2. Perhaps whether activate auto-detection or not could be
a user option.

                    /L/e/k/t/u

Re: Image mode

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/6/07, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> OK, here is my stab at this.
>
> Thanks.
>
>> Here are three schemes.
>
> AFAICS, all schemes are abandoning the idea of protecting (or at least
> warning) the user against potentially dangerous but correctly named
> image files; is that so?

Why would a user open a binary file in anything but hexl-mode?

-- 
David Kastrup

Re: Image mode

[Juanma Barranquero]

On 2/6/07, David Kastrup <dak@gnu.org> wrote:

> Why would a user open a binary file in anything but hexl-mode?

When the binary file is an image? Are you serious?

                    /L/e/k/t/u

Re: Image mode

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/6/07, David Kastrup <dak@gnu.org> wrote:
>
>> Why would a user open a binary file in anything but hexl-mode?
>
> When the binary file is an image? Are you serious?

Why would he open a binary image file in Emacs without wanting to have
it treated as an image, and without wanting to see it in hex?

I don't see what is so funny about the question.  At least some people
(including Richard) are arguing that a user opening a file with a
well-known binary image extension should not get an image view by
default.

And I ask why a user would open a binary image file in Emacs (short of
using hexl-mode) if he did not intend to see it as an image?

-- 
David Kastrup

Re: Image mode

[Juanma Barranquero]

On 2/6/07, David Kastrup <dak@gnu.org> wrote:

> And I ask why a user would open a binary image file in Emacs (short of
> using hexl-mode) if he did not intend to see it as an image?

Let's not go in circles. My remark, that you quoted, was not about the
user opening binary images as other than images, but whether we would
warn the user or not that images could be dangerous.

I don't like the warning; but for a while we were doing it, and it
seems that with Chong's proposed answers, we won't now (although I'm
not sure what's the status after Richard's latest comment). I was
asking whether we had changed the policy.

                    /L/e/k/t/u

Re: Image mode

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/6/07, David Kastrup <dak@gnu.org> wrote:
>
>> And I ask why a user would open a binary image file in Emacs (short
>> of using hexl-mode) if he did not intend to see it as an image?
>
> Let's not go in circles. My remark, that you quoted, was not about
> the user opening binary images as other than images, but whether we
> would warn the user or not that images could be dangerous.
>
> I don't like the warning; but for a while we were doing it, and it
> seems that with Chong's proposed answers, we won't now (although I'm
> not sure what's the status after Richard's latest comment). I was
> asking whether we had changed the policy.

If there ever was a "policy" instead of just an implementation, I
don't think it was sensible.  Image libraries are not inherently
insecure (like, say, setuid shellscripts are).  We don't warn users
before starting an X session even though there are sometimes
vulnerabilities found in the Xlib library.

The only safe way around those vulnerabilities is to compile Emacs
without those libraries.

Short of that, there is some "reasonable expectation" of what will and
what will not happen.

If the user _knows_ that Xlib is a current attack vector, she has the
option of using "emacs -nw".  In a similar vein, if she knows about a
jpeg library vulnerability, she might refrain from opening "xxx.jpg"
in Emacs.

Our current scheme is not completely usable for the sake of manual
corruption prevention since it is possible to name a JPEG file
"xxx.png", and a user knowing about a JPEG vulnerability would open
it unsuspectingly.

On the other hand, there are cases of thumbnail files with the same
file name (including extension) as their source image, but a different
file format.

The "minimized amount of surprise" would ask if the auto detection
arrives at a different image format (not just at a different
is-an-image-p) than the extension.

As long as file type and extension are compatible, I see no reason for
user feedback before treating the file as an image.

-- 
David Kastrup

Re: Image mode

[Juanma Barranquero]

On 2/6/07, David Kastrup <dak@gnu.org> wrote:

> If there ever was a "policy" instead of just an implementation,

It was a policy by implementation :)

> If the user _knows_ that Xlib is a current attack vector, she has the
> option of using "emacs -nw".  In a similar vein, if she knows about a
> jpeg library vulnerability, she might refrain from opening "xxx.jpg"
> in Emacs.

For this discussion it doesn't make much sense IMO to talk about the
vulnerabilities the user knows about.

> As long as file type and extension are compatible, I see no reason for
> user feedback before treating the file as an image.

I'm not in favor of the warning, but I agree with Richard in that I
don't see any reason to treat files with valid image extensions (in
agreement or disagreement with its contents) different that images
with no recognizable extension. The way for a virus to enter a system
is profiting from the familiarity. Either you trust your images'
source, or you don't.

                    /L/e/k/t/u

Re: Image mode

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/6/07, David Kastrup <dak@gnu.org> wrote:
>
>> If there ever was a "policy" instead of just an implementation,
>
> It was a policy by implementation :)
>
>> If the user _knows_ that Xlib is a current attack vector, she has
>> the option of using "emacs -nw".  In a similar vein, if she knows
>> about a jpeg library vulnerability, she might refrain from opening
>> "xxx.jpg" in Emacs.
>
> For this discussion it doesn't make much sense IMO to talk about the
> vulnerabilities the user knows about.

Well, _we_ don't know about any vulnerabilities either at the moment,
so it would seem that it does not make much sense to talk about
anything in this discussion.

Not that it does not feel like that...

>> As long as file type and extension are compatible, I see no reason
>> for user feedback before treating the file as an image.
>
> I'm not in favor of the warning, but I agree with Richard in that I
> don't see any reason to treat files with valid image extensions (in
> agreement or disagreement with its contents) different that images
> with no recognizable extension. The way for a virus to enter a
> system is profiting from the familiarity. Either you trust your
> images' source, or you don't.

Sorry, but that is nonsense.  We have added a lot of stuff warning
about file variables and unsafe variables and so on, exactly to free
the user from having to worry about the trustworthiness of files
before opening them.  And are you telling me that all the junk mails
that want me to click on something have a sender I know?

The user has an idea about what Emacs will do with a file, and will
judge based on that whether he wants it to open in Emacs in this
manner.  If Emacs does something different than the expected thing,
there goes one component of security: user wariness.

-- 
David Kastrup

Re: Image mode

[Juanma Barranquero]

On 2/6/07, David Kastrup <dak@gnu.org> wrote:

> Well, _we_ don't know about any vulnerabilities either at the moment,
> so it would seem that it does not make much sense to talk about
> anything in this discussion.

Very funny, but obviously we were talking about the (possibility of)
vulnerabilities the user *doesn't* know about...

> Not that it does not feel like that...

More and more...

> And are you telling me that all the junk mails
> that want me to click on something have a sender I know?

No. I'm saying that the virus your computer will catch won't come in a
.jpg file hiding as a .c or .txt or whatever. It will come in a .jpg
"hiding" as a .jpg from a source you'll consider trusted or, at the
very least, non threatening.

                    /L/e/k/t/u

Re: Image mode

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/6/07, David Kastrup <dak@gnu.org> wrote:
>
>> Well, _we_ don't know about any vulnerabilities either at the moment,
>> so it would seem that it does not make much sense to talk about
>> anything in this discussion.
>
> Very funny, but obviously we were talking about the (possibility of)
> vulnerabilities the user *doesn't* know about...
>
>> Not that it does not feel like that...
>
> More and more...
>
>> And are you telling me that all the junk mails
>> that want me to click on something have a sender I know?
>
> No. I'm saying that the virus your computer will catch won't come in a
> .jpg file hiding as a .c or .txt or whatever. It will come in a .jpg
> "hiding" as a .jpg from a source you'll consider trusted or, at the
> very least, non threatening.

But it cannot be the business of Emacs to decide about the
trustworthiness of a source.  It is the job of the user.  And it also
is the choice of the user whether he trusts a particular image library
for opening a particular file from a particular source.  The user
can't do this job if he is mistaken about the libraries that will
likely get used.

Anyway, I say you are wrong: lots of attacks are done by having people
click on links and/or let them open file types that look like they are
something different.

My arguments revolve about letting the user do his part with regard to
security, yours revolve about the user being incapable to do it, and
letting Emacs do a job that can't be done by it.

-- 
David Kastrup

Re: Image mode

[Juanma Barranquero]

On 2/6/07, David Kastrup <dak@gnu.org> wrote:

> But it cannot be the business of Emacs to decide about the
> trustworthiness of a source.

No.

> And it also
> is the choice of the user whether he trusts a particular image library
> for opening a particular file from a particular source.  The user
> can't do this job if he is mistaken about the libraries that will
> likely get used.

Yours is a very sophisticate user. Mine is not. I don't expect him,
for example, to know that opening a TIFF could expose him to a JPEG or
ZLib vulnerability.

> Anyway, I say you are wrong: lots of attacks are done by having people
> click on links and/or let them open file types that look like they are
> something different.

And a lot others by people trusting executables, images, etc.
downloaded from emule, that are exactly what the user expected, sans
the surprise.

> yours revolve about the user being incapable to do it, and
> letting Emacs do a job that can't be done by it.

In fact, if anything I'm arguing against security warnings; my point
is that we cannot reliably protect the user. Believing that a match
between contents and file extension should somehow be more trusted is
false security.

                    /L/e/k/t/u

Re: Image mode

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> In fact, if anything I'm arguing against security warnings; my point
> is that we cannot reliably protect the user. Believing that a match
> between contents and file extension should somehow be more trusted
> is false security.

I wish you'd stop beating this strawman.  We are not talking about
Emacs trusting a file.  We are talking about letting the _user_ make
an informed decision what he considers ok to do with the file.  When
the user tells Emacs "open this JPEG file", and Emacs would not open
it as a JPEG file, it should tell the user that it is going to attempt
something different.

-- 
David Kastrup

Re: Image mode

[Juanma Barranquero]

On 2/6/07, David Kastrup <dak@gnu.org> wrote:

> I wish you'd stop beating this strawman.

Your wishes are granted.

                    /L/e/k/t/u

Re: Image mode

[Richard Stallman]

    But it cannot be the business of Emacs to decide about the
    trustworthiness of a source.  It is the job of the user.

Most users don't have any idea how to judge this, any more than I do.
It would never occur to us to suspect that displaying an image as an
image might do some harm.  And even if we did think of the
possibility, there is no practical thing we could do about it.  If I
want to see what the image looks like, what am I going to do except
view it?

What good does it do me to avoid displaying a image named foo.txt
if I don't avoid displaying an image named foo.jpg?

    In fact, if anything I'm arguing against security warnings; my point
    is that we cannot reliably protect the user. Believing that a match
    between contents and file extension should somehow be more trusted is
    false security.

I think so too.

Re: Image mode

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     But it cannot be the business of Emacs to decide about the
>     trustworthiness of a source.  It is the job of the user.
>
> Most users don't have any idea how to judge this, any more than I
> do.

I have more of an opinion about the various people sending me mail
than Emacs ever will.

> It would never occur to us to suspect that displaying an image as an
> image might do some harm.  And even if we did think of the
> possibility, there is no practical thing we could do about it.  If I
> want to see what the image looks like, what am I going to do except
> view it?

But the user can decide whether he wants to view an image.  He can't
decide this if there is no indication for him that Emacs is going to
treat the file as an image when opening it.

> What good does it do me to avoid displaying a image named foo.txt if
> I don't avoid displaying an image named foo.jpg?

Who is "I"?  If it is supposed to be "Emacs", we are not concerned
about its good: it is not a sentient being.  If it is supposed to be
"Richard", I should be surprised seeing you display an image.

There is no sense in continuing to conflate user and editor.

I am, by now, sick to the bone of continuing arguing against this
nonsensical proposition that the user is too stupid to even be allowed
to have a word in deciding whether he wants something viewed or not.

_We_ can only cater for the job of Emacs.  We can't replace the user.
It is the user who will have to clean up the computer after an attack.
So it is only fair that we give him the information he needs for a
qualified decision _Emacs_ can't possibly make.  If he can't use this
information to his advantage, it is still _his_ responsibility, and he
can learn.

It is like democracy.  Most people appear incapable of casting a
well-qualified and well-informed vote, but there is nobody else to do
the job, and they are the ones, after all, that have to bear the
consequences.

>     In fact, if anything I'm arguing against security warnings; my
>     point is that we cannot reliably protect the user. Believing
>     that a match between contents and file extension should somehow
>     be more trusted is false security.
>
> I think so too.

This is my last contribution to this thread, since I am thoroughly
sick of people repeating do thresh that dead straw horse.

For crying out loud: a match between contents and file extension
merely indicates that we have no security-relevant information to
provide to the user that he can not reasonably expect, anyway.  This
is _not_ about Emacs trusting a file: it is about giving the user
information that lets him decide whether to trust having it displayed
in the manner Emacs would choose when looking at its contents (which
the user has had no possibility to examine yet) as opposed to its
filename (which the user has already seen).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Image mode

[Richard Stallman]

    > Most users don't have any idea how to judge this, any more than I
    > do.

    I have more of an opinion about the various people sending me mail
    than Emacs ever will.

You are unusual.  Most users don't have any idea how to judge such a
question, and would not even ask themselves the question.

    So it is only fair that we give him the information he needs for a
    qualified decision _Emacs_ can't possibly make.  If he can't use this
    information to his advantage, it is still _his_ responsibility, and he
    can learn.

I cannot agree with the idea of placing such demands on the user
because I know I could not possibly meet them.

Re: Image mode

[Richard Stallman]

    > What good does it do me to avoid displaying a image named foo.txt if
    > I don't avoid displaying an image named foo.jpg?

    Who is "I"?  If it is supposed to be "Emacs", we are not concerned
    about its good: it is not a sentient being.  If it is supposed to be
    "Richard", I should be surprised seeing you display an image.

We're talking about users' displaying images by means of Emacs commands.
"I" refers to me.

Re: Image mode

[Stuart D. Herring]

> What good does it do me to avoid displaying a image named foo.txt
> if I don't avoid displaying an image named foo.jpg?

Displaying an image carries some risk, while (to the best of everyone's
knowledge) displaying any data whatever in an Emacs buffer as text
(possibly with control characters, or with hexl-mode) is safe.  So a user
presented with two plausible files from an untrusted source, foo.txt and
foo.jpg, might sensibly examine the text file first to see if it is
legitimate.  If, however, the files have the same malicious contents, and
Emacs helpfully renders the .txt file as an image, the user's caution is
vain.  Yes, not all users have such caution, but they are not harmed by a
policy which treats misnamed files as suspect.

The point is that all users, whether they know about the risks or not,
mean for Emacs to render a JPEG if they M-x find-file foo.jpg, because
that is really the only useful thing Emacs could do there.  When -some-
users M-x find-file foo.txt, they are specifically wanting Emacs -not- to
render the file as an image, because they are being careful and dealing
only in text.  Other users who would see the JPEG data and think only
"huh, this is garbage" rather than "wow, it really was an image posing as
text" would benefit from image-minor-mode and its helpful minibuffer
message about C-c C-c.  In either case, starting the major mode associated
with the file's extension is probably appropriate.

So for some users, recognizing but failing to render an image.txt is
helpful, and for others it does no real harm.  And for all users,
recognizing and rendering an image.jpg is sensible.  All of this should of
course be customizable: `image-render-immediately', defaulting to t
because permanent paranoia should be opt-in, and
`image-render-nonimage-immediately', defaulting to nil because users
should not have to be paranoid about text files.

Finally, the ".txt" extension here could just as easily be ".png"; if the
image is in fact a JPEG, we have the case where a user has just patched
their PNG library but not their JPEG library.  I suppose that it is more
common to merely distinguish images from not, so perhaps a third option
`image-render-misnamed-immediately' defaulting to t would be appropriate.

Davis

PS The default values I offer here end up being a selection from the list
of options that has been going around, but they are not the point!  The
point is to illustrate why the behavior could be usefully different for
different extensions.

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Image mode

[Chris Moore]

"Stuart D. Herring" <herring@lanl.gov> writes:

> Finally, the ".txt" extension here could just as easily be ".png"; if the
> image is in fact a JPEG, we have the case where a user has just patched
> their PNG library but not their JPEG library.  I suppose that it is more
> common to merely distinguish images from not,

What about files with extensions of ".blah"?  If they contain image
data, are they misnamed?  I would expect to be safe opening a .blah
file, knowing that it's not a recognised extension, I feel safe
knowing it'll be opening in fundamental-mode.  It seems several people
on the list would rather display this .blah file as an image.

Re: Image mode

[Stuart D. Herring]

>> Finally, the ".txt" extension here could just as easily be ".png"; if
>> the
>> image is in fact a JPEG, we have the case where a user has just patched
>> their PNG library but not their JPEG library.  I suppose that it is more
>> common to merely distinguish images from not,
>
> What about files with extensions of ".blah"?  If they contain image
> data, are they misnamed?  I would expect to be safe opening a .blah
> file, knowing that it's not a recognised extension, I feel safe
> knowing it'll be opening in fundamental-mode.  It seems several people
> on the list would rather display this .blah file as an image.

As I said in my reply to Chong (or, pardon me, is it Yidong?)'s
suggestion, I think that failed matches in auto-mode-alist -- that is,
files like .blah that would generate Fundamental Mode -- should be treated
as are files that match something in auto-mode-alist but not an image
mode.  (And perhaps, again, as should be files that match an image mode
but not the right type of image.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Image mode

[Chong Yidong]

Chris Moore <dooglus@gmail.com> writes:

> > I disagree.  Firefox is primarily for displaying text, and
> > Openoffice.org is commonly used for editing formatted text.
>
> Firefox is a web browser (it views but doesn't edit a mixture of text
> and images) and Openoffice.org is an ofice suite (allowing the editing
> of text, spreadsheets, databases, drawings, etc).

The important point is that these programs have to make a choice about
whether to handle a file as an image or as text, just as Emacs does.

> What about files with extensions of ".blah"?  If they contain image
> data, are they misnamed?  I would expect to be safe opening a .blah
> file, knowing that it's not a recognised extension, I feel safe
> knowing it'll be opening in fundamental-mode.  It seems several people
> on the list would rather display this .blah file as an image.

It's not merely an idiosyncrasy of the people on this mailing list.
Firefox, for example, has settled on this behavior: i.e., handle a
file as an image if it is autodetected as an image and we can't find
another match for it in (Firefox's equivalent of) auto-mode-alist.

Re: Image mode

[Richard Stallman]

    The point is that all users, whether they know about the risks or not,
    mean for Emacs to render a JPEG if they M-x find-file foo.jpg, because
    that is really the only useful thing Emacs could do there.  When -some-
    users M-x find-file foo.txt, they are specifically wanting Emacs -not- to
    render the file as an image, because they are being careful and dealing
    only in text.  Other users who would see the JPEG data and think only
    "huh, this is garbage" rather than "wow, it really was an image posing as
    text" would benefit from image-minor-mode and its helpful minibuffer
    message about C-c C-c.  In either case, starting the major mode associated
    with the file's extension is probably appropriate.

    So for some users, recognizing but failing to render an image.txt is
    helpful, and for others it does no real harm.  And for all users,
    recognizing and rendering an image.jpg is sensible.

I think you have convinced me that there is some benefit in treating
the contents-extension mismatch case differently from the case where
they match.

So I am led to think of these rules:

1. If the file name indicates an image type and the contents match it,
use image mode.

2. If the file name has no meaning and the contents indicate an image,
use Fundamental mode and Image minor mode.

3. If the file name has a meaning which conflicts with the image type,
obey the file name.

#3 is mostly the case after Yidong's latest change.  The only change
proposed in #3 is that a file foo.jpg which contains a PNG should be
treated as a case of #3.


All of this is separate from the question of whether to display an image
immediately even in case 1.

Re: Image mode

[Chris Moore]

On 2/12/07, Richard Stallman <rms@gnu.org> wrote:
> 3. If the file name has a meaning which conflicts with the image type,
> obey the file name.
>
> #3 is mostly the case after Yidong's latest change.  The only change
> proposed in #3 is that a file foo.jpg which contains a PNG should be
> treated as a case of #3.

I'm not sure that displaying PNG content using the JPG library is ever
worth doing - it will almost certainly not work.  Better would be to
prompt "foo.jpg contains a PNG image; display it?"

Re: Image mode

[Richard Stallman]

    > 3. If the file name has a meaning which conflicts with the image type,
    > obey the file name.
    >
    > #3 is mostly the case after Yidong's latest change.  The only change
    > proposed in #3 is that a file foo.jpg which contains a PNG should be
    > treated as a case of #3.

    I'm not sure that displaying PNG content using the JPG library is ever
    worth doing - it will almost certainly not work.

I think that is a misunderstanding.  When I speak of obeying the file
name I don't mean displaying foo.jpg as an image, because I expected
that Emacs would be detecting JPEGs anyway.  In any case, I agree with you
that this is not the desired behavior.

Re: Image mode

[Richard Stallman]

    Sorry, but that is nonsense.  We have added a lot of stuff warning
    about file variables and unsafe variables and so on, exactly to free
    the user from having to worry about the trustworthiness of files
    before opening them.

That is a different kind of issue.  No bug in Emacs is needed for a
file to cause trouble if it can set a variable whose value is a
function to be executed.  The features we have installed to check file
local variables are the only line of defense against that.

The image issue is different because the image library is a line of
defense against viruses in images.

      And are you telling me that all the junk mails
    that want me to click on something have a sender I know?

I don't think that is what he said.

    The user has an idea about what Emacs will do with a file, and will
    judge based on that whether he wants it to open in Emacs in this
    manner.

The beginning user sees .jpg and thinks "this is an image; Emacs will
display it."  If displaying that image will cause some sort of harm,
he doesn't know any better.

    If Emacs does something different than the expected thing,
    there goes one component of security: user wariness.

Most users are not wary of images.

Re: Image mode

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     The user has an idea about what Emacs will do with a file, and
>     will judge based on that whether he wants it to open in Emacs in
>     this manner.
>
> The beginning user sees .jpg and thinks "this is an image; Emacs
> will display it."  If displaying that image will cause some sort of
> harm, he doesn't know any better.

But neither does Emacs.  So there is no sense in Emacs making it more
complicated for the user to display an image.

>     If Emacs does something different than the expected thing, there
>     goes one component of security: user wariness.
>
> Most users are not wary of images.

That's their problem.  And Emacs _can't_ be wary of images since its
knowledge about potential library problems is fuzzy and much weaker
than that of the library authors.

So Emacs can't help users to learn in a sensible manner.  It can, at
best, disturb them.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Image mode

[Richard Stallman]

    > The beginning user sees .jpg and thinks "this is an image; Emacs
    > will display it."  If displaying that image will cause some sort of
    > harm, he doesn't know any better.

    But neither does Emacs.  So there is no sense in Emacs making it more
    complicated for the user to display an image.

I agree with this conclusion, but I get there in a different way.

    > Most users are not wary of images.

    That's their problem.

Whatever bad thing happens to the user, it is the user's problem.  Our
problem is to try to eliminate likely causes of bad results from use
of Emacs.  That includes bad results due to viewing an image named
foo.jpg, and bad results due to viewing an image named foo.c.

I don't see any sense in adding an inconvenience to deal with the
latter case while ignoring the former.  That would be barring the
window while the door is open.

However, for reasons of confusion over what C-c C-c should do, I now
agree that we should not automatically turn on Image minor mode when
some major mode has been recognized from the file name.

Re: Image mode

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
> Also, setting image-minor-mode is naughty: it violates the standard
> that Emacs does not automatically turn on minor-modes on for the user.

I've never heard of this "standard", but assuming it exists, why is it
important as more than a general guideline?  Having appropriate minor
modes turned on automatically seems quite reasonable to me...

[What's important is that I be able to override the behavior, and I
guess that would be easy as long as the "automatic" minor modes get
turned on before the major mode hook gets run.]

> Personally, I think scheme 2 may be a good compromise.

I agree.

[In particular, I like the behavior with respect to .xpm files (which is
one of the few cases being discussed that actually happens in practice);
sometimes I want to open them as image files, sometimes as C files, but
I strongly dislike being prompted.  "scheme 2"s behavior of defaulting
to one mode or the other and having a convenient keystroke to switch
seems like the best thing in such a case.]

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Image mode

[Slawomir Nowaczyk]

On Mon, 05 Feb 2007 18:50:14 -0500
Chong Yidong <cyd@stupidchicken.com> wrote:

#> "Juanma Barranquero" <lekktu@gmail.com> writes:
#> 
#> > On 2/5/07, Chong Yidong <cyd@stupidchicken.com> wrote:
#> >
#> >> So: can anyone provide an alternative?
#> >
#> > I think the first step would be to summarize the existing
#> > alternatives.
#> 
#> OK, here is my stab at this.
<snip>

Looks good to me...

One question: is the difference between schemes 1 and 2 only in the fact
whether user is asked or not? 

#> Personally, I think scheme 2 may be a good compromise.

I prefer scheme 1, but I would like to have some way of controlling
*how* the user is asked... some option like question-inhibit or
something -- this would also allow turning the question off in things
like find-file-noselect.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

Lord, make my words as sweet as honey, for one day I may have to eat them.

Re: Image mode

[Stefan Monnier]

> Scheme 3: No image autodetection
>  - Images are not autodetected.  Only auto-mode-alist is used.
>  - In particular, XPM and XBM images are opened in C mode (see above).

It would make a lot of sense to add entries to auto-mode-alist so as to open
*.xpm and *.xbm in "c-mode + image-minor-mode".  Similarly, postscript-mode
(c|sh)ould automatically turn on image-minor-mode.

> Personally, I think scheme 2 may be a good compromise.

I prefer scheme number 3, of course: it's the simplest of all.

Also users know how to tweak auto-mode-alist to get the mode they want for
specific files, and we've already seen several people annoyed/surprised that
it doesn't work when the mode is detected by magic-mode-alist, so I think
that as much as possible we should stick to using only auto-mode-alist.


        Stefan

Re: Image mode

[Jason Rumney]

Stefan Monnier wrote:
> It would make a lot of sense to add entries to auto-mode-alist so as to open
> *.xpm and *.xbm in "c-mode + image-minor-mode".  Similarly, postscript-mode
> (c|sh)ould automatically turn on image-minor-mode.
>   

This is how it was before the magic-mode-alist changes were made. My 
recent patch to use image-mode-maybe instead of image-mode in 
magic-mode-alist should have restored this feature.

The problem is now people are proposing to use image-mode-maybe for a 
different purpose, and when I brought up that the change would break the 
original use of image-mode-maybe, the suggestion was to make the change 
anyway and introduce a new function to do the old job of 
image-mode-maybe. This seems backwards to me, which is why I suggest we 
leave things as they are and get on with the release, and redesign 
things properly after the release.

Re: Image mode

[Chong Yidong]

Jason Rumney <jasonr@gnu.org> writes:

> Stefan Monnier wrote:
>> It would make a lot of sense to add entries to auto-mode-alist so as to open
>> *.xpm and *.xbm in "c-mode + image-minor-mode".  Similarly, postscript-mode
>> (c|sh)ould automatically turn on image-minor-mode.
>>   
> This is how it was before the magic-mode-alist changes were made. My
> recent patch to use image-mode-maybe instead of image-mode in
> magic-mode-alist should have restored this feature.
>
> The problem is now people are proposing to use image-mode-maybe for a
> different purpose, and when I brought up that the change would break
> the original use of image-mode-maybe, the suggestion was to make the
> change anyway and introduce a new function to do the old job of
> image-mode-maybe. This seems backwards to me, which is why I suggest
> we leave things as they are and get on with the release, and redesign
> things properly after the release.

The problem is that while the behavior of image-mode-maybe suits
text-based image files, it does not seem to do the right thing for
binary image files.  This should be fixed before the release.

Re: Image mode

[Jason Rumney]

Chong Yidong wrote:
> The problem is that while the behavior of image-mode-maybe suits
> text-based image files, it does not seem to do the right thing for
> binary image files.  This should be fixed before the release.
>   

I'm not sure what you mean here. image-mode-maybe does not care whether 
the major-mode it activates is "text" or "binary".

I think what you are saying is that it should not use c-mode for file.c 
if file.c looks like an image. But this is where the whole security 
concern started, and it seems that the majority of people prefer Emacs 
not to default to image-mode for such a misleadingly named file. Anyway, 
such a case is rare and not worth arguing over as much as has happened 
on this thread.

Re: Image mode

[Chong Yidong]

Jason Rumney <jasonr@gnu.org> writes:

> Chong Yidong wrote:
>> The problem is that while the behavior of image-mode-maybe suits
>> text-based image files, it does not seem to do the right thing for
>> binary image files.  This should be fixed before the release.
>
> I'm not sure what you mean here. image-mode-maybe does not care
> whether the major-mode it activates is "text" or "binary".

That's the problem.

> I think what you are saying is that it should not use c-mode for
> file.c if file.c looks like an image. But this is where the whole
> security concern started, and it seems that the majority of people
> prefer Emacs not to default to image-mode for such a misleadingly
> named file. Anyway, such a case is rare and not worth arguing over as
> much as has happened on this thread.

I would argue that if file.c looks like an image, it should not even
turn on image-minor-mode; it should just try displaying in c-mode.

Re: Image mode

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> I would argue that if file.c looks like an image, it should not even
> turn on image-minor-mode; it should just try displaying in c-mode.

There are two variants here:

- Either file.c is an image which is also valid C code (e.g. xpm),
in which case it makes sense to open it in c-mode, show it as text,
but also enable image-minor-mode so C-c C-c will show the image.

- Or file.c is an image which is NOT valid C code (e.g. jpeg), in 
which case c-mode is a bad choice!! So in this case, why should
we show the file in c-mode ?  Why not fundamental-mode or hexl-mode?
OTOH, I'm not sure whether image(-minor)-mode should be applied here.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Image mode

[Chong Yidong]

storm@cua.dk (Kim F. Storm) writes:

[ For a jpeg image saved as foo.c ]

> - Or file.c is an image which is NOT valid C code (e.g. jpeg), in 
> which case c-mode is a bad choice!! So in this case, why should
> we show the file in c-mode ?  Why not fundamental-mode or hexl-mode?
> OTOH, I'm not sure whether image(-minor)-mode should be applied here.

I think that in this, case, we should avoid being too smart for our
own good.  After all, our autodetection heuristics are not foolproof.
For example, a text file containing just the string "GIF89a" will be
autodetected as a gif file!  If the filename indicates it is a text
file, we should respect that.

Re: Image mode

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
> [ For a jpeg image saved as foo.c ]
>
>> - Or file.c is an image which is NOT valid C code (e.g. jpeg), in 
>> which case c-mode is a bad choice!! So in this case, why should
>> we show the file in c-mode ?  Why not fundamental-mode or hexl-mode?
>> OTOH, I'm not sure whether image(-minor)-mode should be applied here.
>
> I think that in this, case, we should avoid being too smart for our
> own good.  After all, our autodetection heuristics are not foolproof.
> For example, a text file containing just the string "GIF89a" will be
> autodetected as a gif file!  If the filename indicates it is a text
> file, we should respect that.

That's ok with me (if it brings us closer to an agreement :-) 

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Chong Yidong <cyd@stupidchicken.com> wrote:

> As for rethinking, I have given my plan.  Do you also have a plan (as
> opposed to a plan to make a plan)?

And BTW, I've contributed code, time and ideas to this thread. Do you
have any more specific requirements that I should satisfy before you
stop insinuating that I'm not thinking, or considering, or taking
seriously, or otherwise trying honestly to find a solution?

                    /L/e/k/t/u

Re: Image mode

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/5/07, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> As for rethinking, I have given my plan.  Do you also have a plan (as
>> opposed to a plan to make a plan)?
>
> And BTW, I've contributed code, time and ideas to this thread. Do you
> have any more specific requirements that I should satisfy before you
> stop insinuating that I'm not thinking, or considering, or taking
> seriously, or otherwise trying honestly to find a solution?

If I have given the impression that you are not thinking seriously, I
apologize.

I am merely arguing that it is not necessary to remove the existing
code as a precondition for deciding on how to handle images.  Let's
decide on the behavior before making any further commits to CVS.

Re: Image mode

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/5/07, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> No drama, please.
>
> Why? Are there rules against drama in the list which I'm not aware of?

There are no rules; this was a personal request.  I think technical
arguments are more relevant to this list than emotional ones; you are
free to disagree.

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Chong Yidong <cyd@stupidchicken.com> wrote:

> I think technical
> arguments are more relevant to this list than emotional ones

And the technical argument in suggesting I'm not considering things
was exactly...? I seem to have missed it.

> you are free to disagree.

How very nice of you.

                    /L/e/k/t/u

Re: Image mode

[Richard Stallman]

The vehemence of your statements comes across as an attack, and it is
likely to make everyone in the discussion more hostile and less
willing to listen.

Re: Image mode

[Juanma Barranquero]

On 2/6/07, Richard Stallman <rms@gnu.org> wrote:

> The vehemence of your statements comes across as an attack

What part, the one where I say that it would be better to rethink the
image support, or the other, where I defend against accusations of not
taking the time to consider options just because I don't agree with
them?

On a second thought, perhaps you're referring to the message (for once
short and to the point, I'd say) in which I answer to my arguments
being called strawmen (at least it wasn't a dead horse).

                    /L/e/k/t/u

Re: Image mode

[Richard Stallman]

I don't remember precisely which message, but it was one where you used
some sharp words.

The point is not what technical position you were arguing for.
It was HOW you said it.  If you state the same position in kinder
words, it would be fine.

Re: Image mode

[Juanma Barranquero]

On 2/7/07, Richard Stallman <rms@gnu.org> wrote:

> The point is not what technical position you were arguing for.

My point was that my "sharp words" were an answer to personal attack.

> If you state the same position in kinder words, it would be fine.

I really don't have time to spend being kind to unkind people.

                    /L/e/k/t/u

Re: Image mode

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/7/07, Richard Stallman <rms@gnu.org> wrote:
>
>> The point is not what technical position you were arguing for.
>
> My point was that my "sharp words" were an answer to personal attack.
>
>> If you state the same position in kinder words, it would be fine.
>
> I really don't have time to spend being kind to unkind people.

It is not just the unkind people reading the list.

-- 
David Kastrup

Re: Image mode

[Juanma Barranquero]

On 2/7/07, David Kastrup <dak@gnu.org> wrote:

> It is not just the unkind people reading the list.

You're right, and I apologize to the kind people on this list.

                    /L/e/k/t/u

Re: Image mode

[Richard Stallman]

    > The point is not what technical position you were arguing for.

    My point was that my "sharp words" were an answer to personal attack.

I didn't notice that previous personal attack, but if there was one, that
also shouldn't have been made.  However, please try not to respond
to a personal attack by attacking back.

Re: Image mode

[Richard Stallman]

    - One function in magic-mode-alist autodetects image types that do not
      make sense to edit (jpgs, pngs, etc).  If the result is ambiguous
      (as determined by checking auto-mode-alist), prompt the user about
      whether to use image-mode or the non-image mode specified by
      auto-mode-alist.

    - A second function autodetects image types that do make sense to edit
      (ps, xpm, xbm).  If autodetected, set up the editing mode and turn
      on image-minor-mode.

    - Otherwise, use auto-mode-alist.

I have no objection to this method.

Re: Image mode

[Chris Moore]

Richard Stallman <rms@gnu.org> writes:

>     - One function in magic-mode-alist autodetects image types that do not
>       make sense to edit (jpgs, pngs, etc).  If the result is ambiguous
>       (as determined by checking auto-mode-alist), prompt the user about
>       whether to use image-mode or the non-image mode specified by
>       auto-mode-alist.
>
>     - A second function autodetects image types that do make sense to edit
>       (ps, xpm, xbm).  If autodetected, set up the editing mode and turn
>       on image-minor-mode.
>
>     - Otherwise, use auto-mode-alist.
>
> I have no objection to this method.

If I open a file called just 'readme', I would be very surprised to
see it opened as an image.  'readme' doesn't match anything in
auto-mode-alist, and so presumably wouldn't satisfy your ambiguity
condition.

I would rather not be surprised like this.

If you define 'the result is ambiguous' to include the case where
magic-mode-alist says 'this is an image' and auto-mode-alist says 'I
know nothing' then I also have no objection to this method.

Re: Image mode

[Chong Yidong]

Chris Moore <dooglus@gmail.com> writes:

> If I open a file called just 'readme', I would be very surprised to
> see it opened as an image.  'readme' doesn't match anything in
> auto-mode-alist, and so presumably wouldn't satisfy your ambiguity
> condition.
>
> I would rather not be surprised like this.

Try saving a jpeg file with no extension, and opening it with the
following programs:

  Firefox
  The Gimp
  Evince
  Openoffice.org

You will receive four surprises.

Re: Image mode

[Chris Moore]

Chong Yidong <cyd@stupidchicken.com> writes:

> Try saving a jpeg file with no extension, and opening it with the
> following programs:
>
>   Firefox
>   The Gimp
>   Evince
>   Openoffice.org
>
> You will receive four surprises.

Interesting, but none of them are primarily text editors.  When The
Gimp automatically detects the image type from the file contents,
that's less surprising than when Emacs does it, since The Gimp is for
editing images, whereas Emacs is primarily for editing text files.

Your 4 examples show that it does seem to be acceptable for this kind
of automatic image detection to happen.  I just don't like it, that's
all.  :)

Re: Image mode

[Richard Stallman]

    >   Firefox
    >   The Gimp
    >   Evince
    >   Openoffice.org
    >
    > You will receive four surprises.

    Interesting, but none of them are primarily text editors.

I disagree.  Firefox is primarily for displaying text, and
Openoffice.org is commonly used for editing formatted text.

Re: Image mode

[Chris Moore]

Richard Stallman <rms@gnu.org> writes:

>     >   Firefox
>     >   The Gimp
>     >   Evince
>     >   Openoffice.org
>     >
>     > You will receive four surprises.
>
>     Interesting, but none of them are primarily text editors.
>
> I disagree.  Firefox is primarily for displaying text, and
> Openoffice.org is commonly used for editing formatted text.

Firefox is a web browser (it views but doesn't edit a mixture of text
and images) and Openoffice.org is an ofice suite (allowing the editing
of text, spreadsheets, databases, drawings, etc).

I don't see either of them as being primarily text editors.

Re: Image mode

[Eli Zaretskii]

> From: Chris Moore <dooglus@gmail.com>
> Date: Fri, 09 Feb 2007 18:17:14 +0100
> Cc: mathias.dahl@gmail.com, lekktu@gmail.com, cyd@stupidchicken.com,
> 	jasonr@gnu.org, emacs-devel@gnu.org
> >
> > I disagree.  Firefox is primarily for displaying text, and
> > Openoffice.org is commonly used for editing formatted text.
> 
> Firefox is a web browser (it views but doesn't edit a mixture of text
> and images) and Openoffice.org is an ofice suite (allowing the editing
> of text, spreadsheets, databases, drawings, etc).
> 
> I don't see either of them as being primarily text editors.

For similar reasons, I don't see Emacs as primarily a text editor.

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Jason Rumney <jasonr@gnu.org> wrote:

> I think we should take a step back and design this properly rather than
> introducing more patches.

YES!

At this moment, any patch related to image support is suspicious
unless it *removes* things. In fact, I strongly suggest installing the
following patch (+ ChangeLogs) and starting anew, not committing a
single image-related thing unless we've reached some kind of
agreement.

                    /L/e/k/t/u



Index: lisp/files.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/files.el,v
retrieving revision 1.882
diff -u -2 -r1.882 files.el
--- lisp/files.el	31 Jan 2007 12:37:29 -0000	1.882
+++ lisp/files.el	5 Feb 2007 18:58:22 -0000
@@ -2128,6 +2128,5 @@

 (defvar magic-mode-alist
-  `((image-type-auto-detected-p . image-mode-maybe)
-    ;; The < comes before the groups (but the first) to reduce backtracking.
+  `(;; The < comes before the groups (but the first) to reduce backtracking.
     ;; TODO: UTF-16 <?xml may be preceded by a BOM 0xff 0xfe or 0xfe 0xff.
     ;; We use [ \t\n] instead of `\\s ' to make regex overflow less likely.
Index: lisp/image.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/image.el,v
retrieving revision 1.69
diff -u -2 -r1.69 image.el
--- lisp/image.el	28 Jan 2007 07:09:44 -0000	1.69
+++ lisp/image.el	5 Feb 2007 18:55:10 -0000
@@ -66,22 +66,4 @@
 be of image type IMAGE-TYPE.")

-(defvar image-type-auto-detectable
-  '((pbm . t)
-    (xbm . t)
-    (bmp . maybe)
-    (gif . maybe)
-    (png . maybe)
-    (xpm . maybe)
-    (jpeg . maybe)
-    (tiff . maybe)
-    (postscript . nil))
-  "Alist of (IMAGE-TYPE . AUTODETECT) pairs used to auto-detect image files.
-\(See `image-type-auto-detected-p').
-
-AUTODETECT can be
- - t      always auto-detect.
- - nil    never auto-detect.
- - maybe  auto-detect only if the image type is available
-	    (see `image-type-available-p').")

 (defvar image-load-path nil
@@ -329,5 +311,4 @@
   type)

-
 ;;;###autoload
 (defun image-type-available-p (type)
@@ -339,18 +320,4 @@

 ;;;###autoload
-(defun image-type-auto-detected-p ()
-  "Return t iff the current buffer contains an auto-detectable image.
-Whether image types are auto-detectable or not depends on the setting
-of the variable `image-type-auto-detectable'.
-
-This function is intended to be used from `magic-mode-alist' (which see)."
-  (let* ((type (image-type-from-buffer))
-	 (auto (and type (cdr (assq type image-type-auto-detectable)))))
-    (and auto
-	 (or (eq auto t)
-	     (image-type-available-p type)))))
-
-
-;;;###autoload
 (defun create-image (file-or-data &optional type data-p &rest props)
   "Create an image.
Index: lisp/image-mode.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/image-mode.el,v
retrieving revision 1.20
diff -u -2 -r1.20 image-mode.el
--- lisp/image-mode.el	3 Feb 2007 01:01:01 -0000	1.20
+++ lisp/image-mode.el	5 Feb 2007 18:52:50 -0000
@@ -61,9 +61,15 @@
   (use-local-map image-mode-map)
   (add-hook 'change-major-mode-hook 'image-toggle-display-text nil t)
+  (if (and (display-images-p)
+	   (not (get-text-property (point-min) 'display)))
+      (image-toggle-display)
+    ;; Set next vars when image is already displayed but local
+    ;; variables were cleared by kill-all-local-variables
+    (setq cursor-type nil truncate-lines t))
   (run-mode-hooks 'image-mode-hook)
   (if (display-images-p)
       (message "%s" (concat
 		     (substitute-command-keys
-		      "Type \\[image-toggle-display] to view as ")
+		      "Type \\[image-toggle-display] to view the image as ")
 		     (if (get-text-property (point-min) 'display)
 			 "text" "an image") "."))))
@@ -106,6 +112,5 @@
 		     auto-mode-alist))))
     (if (assoc-default buffer-file-name mode-alist 'string-match)
-	(let ((auto-mode-alist mode-alist)
-	      (magic-mode-alist nil))
+	(let ((auto-mode-alist mode-alist))
 	  (set-auto-mode)
 	  (image-minor-mode t))
@@ -175,14 +180,4 @@
 	  (message "Repeat this command to go back to displaying the file as
text")))))

-;; Don't override the setting from .emacs.
-;;;###autoload (put 'image-toggle-display 'disabled t)
-
-(if (get 'image-toggle-display 'disabled)
-    (put 'image-toggle-display 'disabled "\
-
-Warning: Displaying images in Emacs could be a security risk.
-Please ensure that you are using up-to-date image libraries
-and that the images being displayed come from a trusted source."))
-
 (provide 'image-mode)

Re: Image mode

[Juri Linkov]

> How about this patch?
>
> It brings up the prompt when the image autodetection clashes with
> auto-mode-alist, and restores the old image-mode behavior for all
> other cases.

Thanks, Chong.  This patch seems to lead us more close to the good balance
between treating real risks and convenience of displaying images.

The important part it still misses is a new option that defines what
Emacs should do in case of mismatching between the file extension
and its content.  Asking a question like in your patch would be one
option, but the default I think should be the choice 4 from the list
Juanma posted on this thread, i.e. setting image-minor-mode and
not displaying the image.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Image mode

[Slawomir Nowaczyk]

On Mon, 05 Feb 2007 12:08:30 -0500
Chong Yidong <cyd@stupidchicken.com> wrote:

#> "Juanma Barranquero" <lekktu@gmail.com> writes:
#> 
#> > On 2/5/07, Mathias Dahl <mathias.dahl@gmail.com> wrote:
#> >
#> >> What happened to this:
#> >>
#> >> "The extension of file you are about to open suggests that it is a
#> >> text file, but the content seems to be an image. Do you want to open
#> >> it as an image?"
#> >
#> > What happened is that it required more code and no one offered to implement it.
#> 
#> How about this patch?

Looks great to me!

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

Take my advice, I don't use it anyway.

Re: Image mode

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On 2/5/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
> 
>> Opening an
>> image with C-x C-f seems quite ok to me, at least if I am doing that
>> myself ;-)
> 
> Even if the image lacks a recognized image file extension? I.e., do
> you think that opening a .c file containing a JPEG should
> 
> 1) Start in image-mode and display the image
> 2) Start in C mode, image-minor-mode and display the image
> 3) Start in image-mode and not display the image
> 4) Start in C mode, image-minor-mode and not display the image
> 5) Start in fundamental mode, image-minor-mode and display the image
> 6) Start in fundamental mode, image-minor-mode and not display the image
> 7) Start in C mode and bypass image mode (major and minor)
> 8) Start in fundamental mode and bypass all mode detection

Too me 7 looks safest. Maybe 4, but I believe a hint about how to view 
the image would be better.

Re: Image mode

[Jason Rumney]

Lennart Borgman (gmail) wrote:
>> 4) Start in C mode, image-minor-mode and not display the image
>> 7) Start in C mode and bypass image mode (major and minor)
>
> Too me 7 looks safest. Maybe 4, but I believe a hint about how to view 
> the image would be better.

You do get a hint in case 4 (which is what we do currently).

As Emacs is primarily a text editor, not an image viewer, I don't think 
that the extra step for viewing an image we have now is as bad as some 
people are making out.

Lets get on with the release and if people feel strongly enough, 
redesign things properly after 22.1 is out the door.

Re: Image mode

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Lennart Borgman (gmail) wrote:
>>> 4) Start in C mode, image-minor-mode and not display the image
>>> 7) Start in C mode and bypass image mode (major and minor)
>>
>> Too me 7 looks safest. Maybe 4, but I believe a hint about how to
>> view the image would be better.
>
> You do get a hint in case 4 (which is what we do currently).
>
> As Emacs is primarily a text editor, not an image viewer, I don't
> think that the extra step for viewing an image we have now is as bad
> as some people are making out.
>
> Lets get on with the release and if people feel strongly enough,
> redesign things properly after 22.1 is out the door.

This is a new feature.  We don't want it to go out the door as a
misfeature or feeling that it is a security risk.  I agree that we are
spending too much time on discussing this.  Part of the reason is that
the decision rests with Richard in the end.  It appears to me that his
assessment differs from that of most others including myself.  The
typical timelag of 1 or 2 days for his participation makes it a
drawnout process to get to an agreement with him, and in the meantime
we spend our time infighting and venting frustration.

It is not productive, but there remains little other to do at the
moment, I guess.  AFAICT, slow as this discussion is, it is not
actually holding off the release since Richard is still busy clearing
copyright matters.

-- 
David Kastrup

Re: Image mode

[Lennart Borgman (gmail)]

David Kastrup wrote:

> It is not productive, but there remains little other to do at the
> moment, I guess.


There are still bugs in the file name quoting if someone has time to 
look into it. I have thought quite long I should have time to take it 
up, but since it is quite complicated I have not find it worth a try if 
I do not have time to explain fully.

Re: Image mode

[Mathias Dahl]

> As Emacs is primarily a text editor, not an image viewer, I don't think
> that the extra step for viewing an image we have now is as bad as some
> people are making out.

I know that we are mostly discussing a couple of special scenarios
here, but I still want to point out that we should not forget about
packages like `thumbs.el' and `tumme.el', where the user *want* to
display images. Let's hope those will be left uncrippeled.

Re: Image mode

[Stefan Monnier]

>> As Emacs is primarily a text editor, not an image viewer, I don't think
>> that the extra step for viewing an image we have now is as bad as some
>> people are making out.

> I know that we are mostly discussing a couple of special scenarios
> here, but I still want to point out that we should not forget about
> packages like `thumbs.el' and `tumme.el', where the user *want* to
> display images. Let's hope those will be left uncrippeled.

Of course, these are completely separate matters.


        Stefan

Re: Image mode

[Juri Linkov]

> Even if the image lacks a recognized image file extension? I.e., do
> you think that opening a .c file containing a JPEG should
>
> 1) Start in image-mode and display the image
> 2) Start in C mode, image-minor-mode and display the image
> 3) Start in image-mode and not display the image
> 4) Start in C mode, image-minor-mode and not display the image
> 5) Start in fundamental mode, image-minor-mode and display the image
> 6) Start in fundamental mode, image-minor-mode and not display the image
> 7) Start in C mode and bypass image mode (major and minor)
> 8) Start in fundamental mode and bypass all mode detection

I think 4 is the most reasonable choice.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Image mode

[Lennart Borgman (gmail)]

Juri Linkov wrote:
>> Even if the image lacks a recognized image file extension? I.e., do
>> you think that opening a .c file containing a JPEG should
>>
>> 1) Start in image-mode and display the image
>> 2) Start in C mode, image-minor-mode and display the image
>> 3) Start in image-mode and not display the image
>> 4) Start in C mode, image-minor-mode and not display the image
>> 5) Start in fundamental mode, image-minor-mode and display the image
>> 6) Start in fundamental mode, image-minor-mode and not display the image
>> 7) Start in C mode and bypass image mode (major and minor)
>> 8) Start in fundamental mode and bypass all mode detection
> 
> I think 4 is the most reasonable choice.

To make this simpler: I said 7, but would have very little against 4 too.

Re: Image mode

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

>> Even if the image lacks a recognized image file extension? I.e., do
>> you think that opening a .c file containing a JPEG should
>>
>> 1) Start in image-mode and display the image
>> 2) Start in C mode, image-minor-mode and display the image
>> 3) Start in image-mode and not display the image
>> 4) Start in C mode, image-minor-mode and not display the image
>> 5) Start in fundamental mode, image-minor-mode and display the image
>> 6) Start in fundamental mode, image-minor-mode and not display the image
>> 7) Start in C mode and bypass image mode (major and minor)
>> 8) Start in fundamental mode and bypass all mode detection
>
> I think 4 is the most reasonable choice.

The problem with 4, as I see it, is that the user may not notice the
file is in image-minor-mode.  Typing C-c C-c could then lead to
unexpected behavior.

I think, if we go with autodetection at all, it is better to ask the
user in the event of any confusion, rather than using
image-minor-mode.

Of course, if we scrap image autodetection, there is no problem at all
(in the sense that we don't *expect* Emacs to handle this case).

Re: Image mode

[Stefan Monnier]

> I think, if we go with autodetection at all, it is better to ask the
> user in the event of any confusion, rather than using
> image-minor-mode.

Of course, asking the user is always tricky in case the file is accessed
implicitly via find-file-noselect rather than via something like C-x C-f.


        Stefan

Re: Image mode

[Richard Stallman]

    The problem with 4, as I see it, is that the user may not notice the
    file is in image-minor-mode.  Typing C-c C-c could then lead to
    unexpected behavior.

    I think, if we go with autodetection at all, it is better to ask the
    user in the event of any confusion, rather than using
    image-minor-mode.

That is a valid argument.  I think it leads to the conclusion that
when the file is recognized with some other mode, it should not be
recognized as an image too.

Re: Image mode

[Juanma Barranquero]

On 2/5/07, Kim F. Storm <storm@cua.dk> wrote:

> In fact, I find the current issue of image auto-detection pretty silly.

Image auto-detection, or image security protection?

The two issues are conflated, though image auto-detection as it works
now seems reasonable (though I wouldn't object to its scrapping if
someone proposes anything better, of course).

                    /L/e/k/t/u

Re: Image mode

[Kim F. Storm]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/5/07, Kim F. Storm <storm@cua.dk> wrote:
>
>> In fact, I find the current issue of image auto-detection pretty silly.
>
> Image auto-detection, or image security protection?

I was unclear.

The "current issue" is that doing C-x C-f etc/gnus.pbm opens the file
in "binary" mode, ready to be edited.  Event hitting C-c C-c asks me to
confirm what I really want to view it.  IMO, that's "pretty silly".

> The two issues are conflated, though image auto-detection as it works
> now seems reasonable (though I wouldn't object to its scrapping if
> someone proposes anything better, of course).

Yes, auto-detection as such seems to be ok -- the only problem is to
solve ambiguities (to me Chong's latest approach looks promising).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Image mode

[Chris Moore]

storm@cua.dk (Kim F. Storm) writes:

> Event hitting C-c C-c asks me to
> confirm what I really want to view it.  IMO, that's "pretty silly".

More silly than that is that you also have to confirm if you want to
switch back from viewing the image to the binary view.  That should be
a safe operation, so why the prompt for confirmation?

Re: Image mode

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> In fact, I find the current issue of image auto-detection pretty silly.

Indeed.  But clearly someone's all hot and bothered by the isssue, and
Chong's suggestion is diplomatic.

-Miles

-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: Image mode

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     In contrast, if someone sends me a JPEG image in an email, Gnus
>     will happily show it to me without asking (at least with the
>     settings I'm using).  So where's the protection in that case?
>
> Should we consider that a bug in Gnus?
> (I don't know what the answer is.)

I don't think so.  That is pretty much standard behavior of all
browsers/mail readers, and they are more likely to get an attack
targeted for a hole in the image library.

The expected way of dealing with a vulnerability is wait for the
patch, possibly switching images off or restricting the sites you
visit, until it arrives.

People never upgrading their software and sitting on a net connection
should consider switching off image support.

-- 
David Kastrup

Re: Image mode

[Richard Stallman]

    I don't think so.  That is pretty much standard behavior of all
    browsers/mail readers, and they are more likely to get an attack
    targeted for a hole in the image library.

Which other browsers/mail readers on GNU/Linux behave this way?

Re: Image mode

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

>     In contrast, if someone sends me a JPEG image in an email, Gnus
>     will happily show it to me without asking (at least with the
>     settings I'm using).  So where's the protection in that case?
>
> Should we consider that a bug in Gnus?
> (I don't know what the answer is.)

Switching image display off in a mail reader is like switching it off
in a web browser.  Does Firefox query the user before displaying an
image?  "Warning!  The web page you're browsing contains an image!
Image libraries are sometimes prone to buffer overflows!  Do you
really wish to expose yourself to this danger!!1!?"

Warning users about something that's almost certainly not dangerous is
a huge security risk in itself, because you're inuring the users to
warnings.  The user will answer "Yeah, whatever" when being bothered
with these things, and then when Emacs asks the user "Are you sure you
wish to do an rm -rf?" (or whatever the genuinely dangerous thing it
is), they won't bother to read the warning. 

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

Re: Image mode

[Richard Stallman]

    Switching image display off in a mail reader is like switching it off
    in a web browser.  Does Firefox query the user before displaying an
    image?  "Warning!  The web page you're browsing contains an image!
    Image libraries are sometimes prone to buffer overflows!  Do you
    really wish to expose yourself to this danger!!1!?"

If this argument is valid for Gnus, it seems just as valid for
visiting a file directly with Emacs.

To the extent that image libraries have bugs, there will be some level
of danger in viewing images with Emacs.  That danger will obtain
regardless of whether the image files have expected image extensions.
It doesn't go away just because the JPG is in a file called foo.jpg.

Lars' argument seems to show that we just have to live with it.

Re: Image mode

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     In contrast, if someone sends me a JPEG image in an email, Gnus
>     will happily show it to me without asking (at least with the
>     settings I'm using).  So where's the protection in that case?
>
> Should we consider that a bug in Gnus?
> (I don't know what the answer is.)

The answer is NO.
It is normal behaviour for that sort of programs.

It simply illustrates that programs which are used to display a LOT of
UNKNOWN images from UNTRUSTED sources don't "care" at all about
security of the image libraries.

So IMO, there seem to be very little reason for Emacs to go through
hoops to enforce security for a FEW, usually well-KNOWN images (or
files) from (typically) TRUSTED sources (such as your own PC or 
digital cameras).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Image mode

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     In contrast, if someone sends me a JPEG image in an email, Gnus
>>     will happily show it to me without asking (at least with the
>>     settings I'm using).  So where's the protection in that case?
>>
>> Should we consider that a bug in Gnus?
>> (I don't know what the answer is.)
>
> The answer is NO.
> It is normal behaviour for that sort of programs.
>
> It simply illustrates that programs which are used to display a LOT of
> UNKNOWN images from UNTRUSTED sources don't "care" at all about
> security of the image libraries.

Wrong.  They _rely_ of the image library security, and patches are
considered _urgent_ whenever this is not found the case.  Users _can_
usually turn off image display if they want to, but this is not the
normal mode of operation.

> So IMO, there seem to be very little reason for Emacs to go through
> hoops to enforce security for a FEW, usually well-KNOWN images (or
> files) from (typically) TRUSTED sources (such as your own PC or
> digital cameras).

Can we stop beating that dead horse?  Emacs _can't_ enforce security
on images.  Security is the task of the library, and judging
trustworthiness is the job of the user.

I really think that the only thing we should avoid is doing something
entirely unexpected by the user: treating a file differently than the
user could have expected _without_ looking at the file itself
previously.  And that would be opening a file in a different manner
than expected from the user (and considered safe by him).

Personally, I think we should ask the user before displaying a file
with .png extension as a JPEG instead.  However, I think we certainly
should ask her before displaying a file with .c extension as a JPEG.

Of course, the easiest way to ensure that is not to consider the file
contents at all, only the extension.

If we consider the file contents, then only because we want to cater
for the case where contents and extension lead to different
conclusions.  Asking the user is not amiss, I guess: otherwise he
can't _expect_ that a certain image library is going to open this
file.

It is also a matter of not surprising the user.  Certainly a mismatch
between extension and file innards does not make the file any more or
less secure than if it matches.  But not notifying the user before
doing something different locks him out of the decision about what to
do with JPEG files (for example).

It will also make him look like a fool if he sends the file on and
people on the receiving side can't view it like he does, because they
don't have content-sensitive image detection active.

-- 
David Kastrup

Re: Image mode

[Stefan Monnier]

> Personally, I think we should ask the user before displaying a file
> with .png extension as a JPEG instead.  However, I think we certainly
> should ask her before displaying a file with .c extension as a JPEG.

> Of course, the easiest way to ensure that is not to consider the file
> contents at all, only the extension.

100% agreement.


        Stefan

Re: Image mode

[Stefan Monnier]

> As Richard has argued, IF displaying an image can cause a security
> risk, it doesn't matter whether or not that image was autodetected or
> had the relevant file name.  So let's please not worry about this.

Agreed.  Security in this case is a secondary concern.
So let's not forget the other main problems we're trying to solve:
1 - misdetection of foo.JPG as a non-image.
2 - misdetection of non-images because of the content of unrelated files.
3 - misdetection of thumb-images in special directories.

The first (which started this whole thing) is trivially solved by setting
the stupid variable `auto-mode-case-fold' to t.  The var was only introduced
to allow Richard to default its value to nil because of some undisclosed
reason.

The second is the one that justifies to not auto-display image.  It's been
somewhat solved by tightening the image-detection code, but it can't be made
100% reliable.  Note that I know of no other application which uses such
content-detection to discover whether a file is an image or something else.
All other applications I know either use the file-extension or some
out-of-band metadata (e.g. the mime-type provided by the web-server, usually
itself derived from the file-extension).  Of course, some applications use
the file content to decide *which* image format it's dealing with, but this
is a different problem than the one facing Emacs.

The third could be easily addressed in auto-mode-alist by matching the
directory name rather than the file extension.


        Stefan

Re: Image mode

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Note that I know of no other application which uses such
> content-detection to discover whether a file is an image or
> something else.

Gimp does it.  Rename a file foo.jpg to foo.c and it will still
display the image.

Re: Image mode

[Stefan Monnier]

>> Note that I know of no other application which uses such
>> content-detection to discover whether a file is an image or
>> something else.

> Gimp does it.  Rename a file foo.jpg to foo.c and it will still
> display the image.

Please re-read what I wrote.  GIMP uses the file contents to discover
*which* image it's dealing with, but it's not using it to discover whether
it's an image or not.  It's quite different: I believe there is pretty much
no known overlap between the various image formats used today, so you can
decide which image format it is unambiguously based on the contents.  But in
Emacs if we use content-based detection we have to be ready to deal with an
ambiguity with any other file format, that a whole other ball game.


        Stefan

Re: Image mode

[Chris Moore]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Note that I know of no other application which uses such
> content-detection to discover whether a file is an image or
> something else.

Nautilus (GNOME's file browser) does.  It will display an image file
as a thumbnail of the image even if the file has an unknown
extension.

(If an image file has a wrong but known extension then it isn't
displayed as an image).

Re: Image mode

[Juri Linkov]

> 1 - misdetection of foo.JPG as a non-image.
> 2 - misdetection of non-images because of the content of unrelated files.
> 3 - misdetection of thumb-images in special directories.
>
> The first (which started this whole thing) is trivially solved by setting
> the stupid variable `auto-mode-case-fold' to t.  The var was only introduced
> to allow Richard to default its value to nil because of some undisclosed
> reason.

I second this.  I see no reason not to change the default of
`auto-mode-case-fold' to t.  I'm tired of selecting the necessary mode
manually on files with uppercase file names (e.g. from old archives,
from digital cameras, etc.) and I'm sure many other users have the
same problem.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Image mode

[Slawomir Nowaczyk]

On Sun, 04 Feb 2007 20:40:39 -0500
Chong Yidong <cyd@MIT.EDU> wrote:

#> Juri Linkov <juri@jurta.org> writes:
#> 
#> > A different case is image autodetection.  When the image file has an
#> > extension unusual for image files or has no extension at all, then it
#> > would be a (possibly bad) surprise for the user to see it displayed as
#> > an image.  I agree that there should be an option that by default before
#> > displaying the image from files with non-image extensions should either
#> > ask for confirmation before visiting such file in image-mode, or (better)
#> > visit the file just in image-minor-mode with more explanations shown
#> > in the echo area.
#> 
#> As Richard has argued, IF displaying an image can cause a security
#> risk, it doesn't matter whether or not that image was autodetected or
#> had the relevant file name.  So let's please not worry about this.

I disagree. For me, at least, *all* that matters is if the filename
matches the image contents.

About the only case when I care about security when opening images are
things which I receive in emails (sure, there is a chance a virus image
sits somewhere on my disk or on one of the web pages I view, but if that
is the case, then I am likely to fall victim to it anyway, because I
will likely open it in something else than Emacs).

What I am interested in is making sure that I am safe when I receive an
email containing attachment with .txt or .c extension and I decide to
view it in Emacs. I do *not* want it to display it as an image *without*
asking for confirmation (one way or another).

OTOH, if I decide to open an attachment with .jpeg extension, then I am
apparently willing to trust the source and I am perfectly OK with Emacs
displaying it as an image (if Emacs refuses to display such images, I
will just use Firefox or IrfanView, which are more or less equally
susceptible to attacks)...

Please, trust the user! If I say I want Emacs to open a.jpeg, that means
I want to open an image. If I say I want Emacs to open a.txt, then I
expect this action to be safe.

YMMV, of course, and I do not require the above to the *default*
configuration, but _please_ make this behaviour possible -- and,
preferably, easy to achieve because I really believe that is the only
sane configuration for security-aware users.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

The glass is not half full, nor half empty. The glass is just too big.

Re: Image mode

[Richard Stallman]

    Let's restore this feature back to the reasonable state.  This is simple:
    before visiting an image file, the user sees its extension and by the
    extension can decide whether to display the image or not.  There is
    no need to require from the user typing more keys to do what the user
    already decided to do.

If some images are dangerous, the file extension cannot
tell you whether a given image is dangerous.

Re: Image mode

[Chris Moore]

Richard Stallman <rms@gnu.org> writes:

> If some images are dangerous, the file extension cannot
> tell you whether a given image is dangerous.

No it can't, but the fact that I've seen the extension and still want
to open the image means that I'm willing to trust the image library to
display this file, perhaps because I have my antivirus program set to
scan all .jpg files whenever they are opened, for example.

I don't have my antivirus program set to scan all .txt files when they
are opened, because I trust my applications not to attempt to display
.txt files as images (or to run them as binaries, etc).  I think that
is a reasonable thing to expect of any application.

Re: Image mode

[Richard Stallman]

    No it can't, but the fact that I've seen the extension and still want
    to open the image means that I'm willing to trust the image library to
    display this file,

Not necessarily.  You might not even know what an image library is.
The only conclusion we can reliably draw is that you trust display of
the image.

		       perhaps because I have my antivirus program set to
    scan all .jpg files whenever they are opened, for example.

That is one possible reason, but there are others. c perhaps because
it never occurred to you to distrust this, or distrust anything that
seems natural to do in your computer, because you are a beginning user
and don't know about such things.

All in all, I don't see that this argument leads to a conclusion that
a decision can rest on.

Re: Image mode

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     No it can't, but the fact that I've seen the extension and still
>     want to open the image means that I'm willing to trust the image
>     library to display this file,
>
> Not necessarily.  You might not even know what an image library is.
> The only conclusion we can reliably draw is that you trust display of
> the image.

Well, so what?  If we don't consider the user's trust relevant, the
only solution can be to never display an image, ever.  Because it
_will_ be the user who decides in the end which images will get
displayed.  Let's not go back to Emacs 20.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Image mode

[Richard Stallman]

    > Not necessarily.  You might not even know what an image library is.
    > The only conclusion we can reliably draw is that you trust display of
    > the image.

    Well, so what?  If we don't consider the user's trust relevant, 

I don't know what you mean by "consider the user's trust relevant".
I cannot say, now, whether I am in favor it or against it.
I certainly said nothing either for or against it in the message
you are responding to.

So I think you're arguing against something I did not say.