Re: [ANNOUNCE] mutt 1.5.16 released
On 2007-06-17 19:46:02 -0600, Kyle Wheeler wrote:
> While you're lecturing me, maybe you can read what I wrote. There's
> important details there that obviously escaped your notice. The fact that
> 'copiousoutput' is in the 'open' lines forces mutt to leave the file there
> (it assumes that the command will produce output on stdout, and thus brings
> up a pager to view it, and so waits to delete the file until I tell it to
> exit the pager). Thus, there is no race condition, and it works correctly
> on all machines no matter how fast they are. The fact that you need to
> press q is a little annoying, but is hardly the equivalent of requiring
> coding.
Hmm, I didn't see it, but this is an annoying and unacceptable hack. To
make it work as expected (without such a hack), one needs some coding.
>> Another point is that the "open" command is under-specified (and doesn't
>> always use the extension to determine the filetype). So, using "open"
>> without more checking concerning what the file really contains to make
>> sure the wanted application is launched is a bit weak on the security
>> side.
>
> It's only weak on the security side if an attacker can convince me to open
> a file I do not recognize and did not request. I'm no lame Outlook Express
> user, this is significantly more difficult than you'd imagine.
How do you know that without checking the file contents? There are
files I need to open (e.g. for my job) and I can't be sure that the
sender's machine has not been compromised.
>> I don't see why
>>
>> type lynx &> /dev/null
>>
>> isn't regarded as code while
>>
>> vi "$@"; true
>>
>> would be regarded as code.
>
> For that matter, why isn't
>
> vi foo.txt
>
> considered code? Or better still, why aren't *all* mailcap entries
> considered code? It's a fuzzy line. I would say that the latter of
> your examples requires more detailed knowledge of your shell
> semantics than the former (and is less portable). But is that a good
> universal definition? No.
I would say the opposite:
Under Linux:
sh-3.1$ echo &> /dev/null
sh-3.1$
Under Solaris:
$ echo &> /dev/null
12909
$
As one can see, the &> form is not portable.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)