emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Image mode


From: Stuart D. Herring
Subject: Re: Image mode
Date: Wed, 7 Feb 2007 08:10:22 -0800 (PST)
User-agent: SquirrelMail/1.4.8-2.el3.7lanl

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]