emacs-devel
[Top][All Lists]
Advanced

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

Re: Image mode


From: David Kastrup
Subject: Re: Image mode
Date: Tue, 06 Feb 2007 13:46:11 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

address@hidden (Kim F. Storm) writes:

> Richard Stallman <address@hidden> 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




reply via email to

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