Re: [ANNOUNCE] mutt 1.5.16 released

[Vincent Lefevre]

On 2007-06-17 05:13:27 +0200, Vincent Lefevre wrote:
> On 2007-06-16 18:46:01 -0400, Derek Martin wrote:
> > > Also the .mailcap (to view attachments with external tools) also
> > > needs programming knowledge.
> > 
> > No it doesn't.  My mailcap has no code in it whatsoever.  Just simple
> > command lines (which is not code).  Typing the name of a program with
> > arguments is not the same as writing code.
> 
> You don't know what you're talking about. This simply doesn't work.
> I'd like to see your mailcap for viewing a PDF under Mac OS X...

I forgot to say, but many mailcap may have a security hole (in part
due to a security hole in Firefox, known for several years but still
unfixed). See

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429052

for instance. I did the exploit (based on some example reported by
someone else in the Mozilla's Bugzilla) with Mutt and the system
mailcap from Debian.

So, modifying the mailcap file also requires security knowledge.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: mutt 1.5.16 released

[Cameron Simpson]

On 16Jun2007 12:46, Mike Hunter <[EMAIL PROTECTED]> wrote:
| What do people think about allowing the user to specify in their muttrc
| what values do and do not constitute a fatal error coming from their
| editor?

It's needless:

  #!/bin/sh
  real-editor ${1+"$@"}
  xit=$?
  case $xit in
3|4)
  xit=0
  ;;
  esac
  exit $xit

| It seems to me mutt *should* react if it is told there's been a
| fatal editor failure, and given that the standard means of communicating
| such an error has occurred is inherently broken, we should allow for
| another means.

A simple "notice-editor-failure" boolean setting would be plenty, and
probably desirable given the flamewar.

Fine tuning can be done with a script as above, but
yes-I-care,no-I-don't would cover a lot of users.

Cheers,
-- 
Cameron Simpson <[EMAIL PROTECTED]> DoD#743
http://www.cskk.ezoshosting.com/cs/

No, Sir. I don't think its safe to look at the speedometer when I'm going
that fast.
- Tom Coradeschi <[EMAIL PROTECTED]>

Re: [ANNOUNCE] mutt 1.5.16 released

[Derek Martin]

On Sun, Jun 17, 2007 at 05:13:27AM +0200, Vincent Lefevre wrote:
> > > Also the .mailcap (to view attachments with external tools) also needs
> > > programming knowledge.
> > 
> > No it doesn't.  My mailcap has no code in it whatsoever.  Just simple
> > command lines (which is not code).  Typing the name of a program with
> > arguments is not the same as writing code.
> 
> You don't know what you're talking about. This simply doesn't work.

You're probably right.  I've only been using mailcap for about 15
years... I probably have no idea what I'm talking about.

FWIW, my mailcap consists of exactly this:

  image/*; gthumb %s
  application/msword; ooffice %s
  application/pdf; evince %s
  application/postscript ; evince %s
  text/html; /usr/bin/htmlview %s ; copiousoutput

No code at all, unless you consider the parameter substitution to be
code... which I don't.  Just simple commands in simple config lines,
none of which I actually wrote myself.  But this is more than
sufficient to meet my needs for viewing attachments.

> I'd like to see your mailcap for viewing a PDF under Mac OS X...

Yeah, I don't use OS X.  My PDF config is above though.

> > Besides which, even if it were necessary, Unix machines normally have
> > system administrators, especially in places where the end users are
> > neither system admins nor programmers.  All that is needed is a
> > sysadmin with half a clue to create a system mailcap that works for
> > everyone.
> 
> So, the sysadmin could also solve the problem with vi...

He could, but he shouldn't have to.  If the problem needs solving,
that's Mutt's job.  A lot of people reading mail on a Unix system are
people who are just starting out with Linux... they have an
inclination to tinker but still they are not programmers, and again,
regardless of whether they are capable or not, it should never be the
user's job to fix flaws in his mail client...  that's the job of the
application developer.  Mutt's designed to work with vi on Unix
systems.. if it can't deal with the stock vi on some systems without
falsely reporting the editor failed, that seems obviously to be a flaw
to me.

> You're really stupid to write that.

That at least is probably true.  There are certainly better ways for
me to be spending my time than arguing with you about this.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpjWLDJjdBLE.pgp
Description: PGP signature

Re: [ANNOUNCE] mutt 1.5.16 released

[Derek Martin]

On Sun, Jun 17, 2007 at 09:48:48AM -0400, Derek Martin wrote:
> He could, but he shouldn't have to.  If the problem needs solving,
> that's Mutt's job.  A lot of people reading mail on a Unix system are
> people who are just starting out with Linux... they have an

s/Linux/Unix/

I know people who started out with Unix by obtaining a sparcstation or
similar from ebay (or computer fair, etc.) and toying with it,
precisely to learn how to be a system administrator (funny the kind of
people you meet when you're a system administrator)...  If they had
seen this behavior when starting to use Mutt, they would have
dismissed Mutt out of hand as being a brain-dead mail client.  And
they would be right to do so.

I'm not saying Mutt is brain dead, but this "feature" certainly makes
it look that way.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgptu6OhauOww.pgp
Description: PGP signature

Re: [ANNOUNCE] mutt 1.5.16 released

[Vincent Lefevre]

On 2007-06-17 09:48:48 -0400, Derek Martin wrote:
> On Sun, Jun 17, 2007 at 05:13:27AM +0200, Vincent Lefevre wrote:
> > > > Also the .mailcap (to view attachments with external tools) also needs
> > > > programming knowledge.
> > > 
> > > No it doesn't.  My mailcap has no code in it whatsoever.  Just simple
> > > command lines (which is not code).  Typing the name of a program with
> > > arguments is not the same as writing code.
> > 
> > You don't know what you're talking about. This simply doesn't work.
> 
> You're probably right.  I've only been using mailcap for about 15
> years... I probably have no idea what I'm talking about.
> 
> FWIW, my mailcap consists of exactly this:
> 
>   image/*; gthumb %s
>   application/msword; ooffice %s
>   application/pdf; evince %s
>   application/postscript ; evince %s
>   text/html; /usr/bin/htmlview %s ; copiousoutput

This does not work under Mac OS X.

> No code at all, unless you consider the parameter substitution to be
> code... which I don't.

But I assume that you're not able to give a mailcap that works under
Mac OS X without a line of code.

Also your mailcap is simplistic. In practice, you should test that
DISPLAY is set before starting an X11 client, so that a fallback can
be used.

> > > Besides which, even if it were necessary, Unix machines normally have
> > > system administrators, especially in places where the end users are
> > > neither system admins nor programmers.  All that is needed is a
> > > sysadmin with half a clue to create a system mailcap that works for
> > > everyone.
> > 
> > So, the sysadmin could also solve the problem with vi...
> 
> He could, but he shouldn't have to.

Then this is also true for the mailcap file.

> If the problem needs solving, that's Mutt's job. A lot of people
> reading mail on a Unix system are people who are just starting out
> with Linux... they have an inclination to tinker but still they are
> not programmers, and again, regardless of whether they are capable
> or not, it should never be the user's job to fix flaws in his mail
> client... that's the job of the application developer. Mutt's
> designed to work with vi on Unix systems.. if it can't deal with the
> stock vi on some systems without falsely reporting the editor
> failed, that seems obviously to be a flaw to me.

The flaw is in vi. This is not Mutt's job to fix flaws in other
software.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: [ANNOUNCE] mutt 1.5.16 released

[Kyle Wheeler]

On Sunday, June 17 at 05:23 PM, quoth Vincent Lefevre:
No code at all, unless you consider the parameter substitution to 
be code... which I don't.


But I assume that you're not able to give a mailcap that works under 
Mac OS X without a line of code.


Well, he may not (and, if he doesn't use OSX, he shouldn't have to), 
but I can:


image/*; open %s; copiousoutput; nametemplate=%s.jpg
text/html; elinks -dump -force-html %s; needsterminal; copiousoutput;
application/pdf; open %s; copiousoutput; nametemplate=%s.pdf
application/msword; open %s; copiousoutput; nametemplate=%s.doc
application/excel; open %s; copiousoutput; nametemplate=%s.xls

Now, granted, I have a few more entries in there than just that, and I 
have a bunch of test= settings so that I can use my mailcap unchanged 
across lots of different computers, but those entries above will work 
just fine, with nary a line of code in sight.


Granted, I also *assume* that elinks exists and is installed, but 
since I'm the guy that installed it, I think that's safe to assume. 
But its easy to add test= entries, like so:


text/html; elinks -dump -force-html %s; needsterminal; copiousoutput; test=type 
elinks &> /dev/null
text/html; links -dump -force-html %s; needsterminal; copiousoutput; test=type 
links &> /dev/null
text/html; lynx -dump -force-html %s; needsterminal; copiousoutput; test=type lynx 
&> /dev/null

Is that code? I don't think so, but... maybe to some people it seems 
like code.


~Kyle
--
I'm as fond of my body as anyone, but if I can be 200 with a body of 
silicon, I'll take it.

   -- Danny Hillis


pgpVD8FGkc4mt.pgp
Description: PGP signature

Re: [ANNOUNCE] mutt 1.5.16 released

[Derek Martin]

On Sun, Jun 17, 2007 at 05:23:44PM +0200, Vincent Lefevre wrote:
> > No code at all, unless you consider the parameter substitution to be
> > code... which I don't.
> 
> But I assume that you're not able to give a mailcap that works under
> Mac OS X without a line of code.

I guess I really don't care, since I don't use OS X, and have no plans
to start any time soon.  Even if that's true, it's hardly a deficiency
of Mutt... it's a deficiency of Mac OS X for lacking reasonable
software for dealing with media types from the command line.  If I
ever did use OS X, I doubt I would read my mail there.  Then again,
while there are always exceptions, I tend to save attachments before
viewing them anyway, so it's (for me) mostly a moot point.

[As a side note, I read my personal mail on a remote server, so
mailcap is almost completely irrelevant in that case.  I transfer
attachments to my local machine, in the exceptionally rare case when I
receive something I actually want to look at, since in most cases
that's much faster than waiting for remote X clients -- and then I
need to transfer the file anyway to work with it.  My work mail I
do read on my local workstation, and that's where the above applies.]

> Also your mailcap is simplistic. In practice, you should test that
> DISPLAY is set before starting an X11 client, so that a fallback can
> be used.

I think I'm perfectly capable of figuring out whether I'm running in X
or not...  If I'm not in X I probably can't view PDF files anyway, at
least not in any useful capacity.  Likewise for all the other formats
that involve graphics.  As I said, the simplistic mailcap works just
fine for me.  There was a time when I used to try to get fancy with my
mailcap, and then I realized I was just wasting time over-engineering
solutions to problems which, practically speaking, didn't really
exist.  I've been using this mailcap, or one extremely similar to it,
for around 5 years now -- probably longer -- and have never had a
problem viewing attachments.

Your assertion that I *need* to write code to support all this is
false, and completely absurd, like most of your other points.  I don't
need to, and have not ever done so.  Aside from the aforementioned
over-engineering of my mailcap (which was probably at a time when I
was using Pine, not Mutt), I have never written code to support my use
of Mutt, other than in Mutt's code itself, to fix bugs or feature
deficiencies in Mutt.

Just because you can do something, doesn't mean you should.  Or be
required to.

> > If the problem needs solving, that's Mutt's job. 

> The flaw is in vi. This is not Mutt's job to fix flaws in other
> software.

Given that vi is adhering strictly to (at least one revision of) the
rather widely accepted and complied-to POSIX standards, that position
is completely unsupportable.  If mutt is going to continue to be
something other than "just another crappy mailer", then Mutt needs to
be capable of dealing with standards which are in common usage.  I
dare say Solaris, and vi on Solaris, are in rather common usage...  I
won't bother to comment about SCO.

Thanks for this mostly pointless debate.  I've had enough.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpXFNRJa78I2.pgp
Description: PGP signature

Re: [ANNOUNCE] mutt 1.5.16 released

[Vincent Lefevre]

On 2007-06-17 10:20:43 -0600, Kyle Wheeler wrote:
> Well, he may not (and, if he doesn't use OSX, he shouldn't have to),
> but I can:
>
> image/*; open %s; copiousoutput; nametemplate=%s.jpg
> text/html; elinks -dump -force-html %s; needsterminal; copiousoutput;
> application/pdf; open %s; copiousoutput; nametemplate=%s.pdf
> application/msword; open %s; copiousoutput; nametemplate=%s.doc
> application/excel; open %s; copiousoutput; nametemplate=%s.xls

Before giving rules, perhaps you should make sure that they really
work everywhere. I can tell you that this doesn't work on my machine,
at least for PDF. You have a race condition here: the "open" command
can return before the application (here, Preview) loads the file. And
as just after "open" returns, Mutt zeros the file and removes it, the
application can get nothing or corrupt data to load. The fact that
my machine is a fast bi-processor machine can have an impact on the
probability of failure. But I suggest that you try that on such a
machine (if you can) with Preview already loaded.

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.

> Now, granted, I have a few more entries in there than just that, and
> I have a bunch of test= settings so that I can use my mailcap
> unchanged across lots of different computers, but those entries
> above will work just fine, with nary a line of code in sight.

I also need a mailcap that works on various machines, where the
current environment is an X11 one or not (hence the test of the
DISPLAY environment variable).

> Granted, I also *assume* that elinks exists and is installed, but since I'm 
> the guy that installed it, I think that's safe to assume. But its easy to 
> add test= entries, like so:
>
> text/html; elinks -dump -force-html %s; needsterminal; copiousoutput; 
> test=type elinks &> /dev/null
> text/html; links -dump -force-html %s; needsterminal; copiousoutput; 
> test=type links &> /dev/null
> text/html; lynx -dump -force-html %s; needsterminal; copiousoutput; 
> test=type lynx &> /dev/null
>
> Is that code? I don't think so, but... maybe to some people it seems like 
> code.

I don't see why

  type lynx &> /dev/null

isn't regarded as code while

  vi "$@"; true

would be regarded as code.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: [ANNOUNCE] mutt 1.5.16 released

[Vincent Lefevre]

On 2007-06-17 12:22:33 -0400, Derek Martin wrote:
> On Sun, Jun 17, 2007 at 05:23:44PM +0200, Vincent Lefevre wrote:
> > But I assume that you're not able to give a mailcap that works under
> > Mac OS X without a line of code.
> 
> I guess I really don't care, since I don't use OS X, and have no plans
> to start any time soon.

And I don't care about the problems with vi under SCO and Solaris,
since I don't use it. :)

> Even if that's true, it's hardly a deficiency of Mutt... it's a
> deficiency of Mac OS X for lacking reasonable software for dealing
> with media types from the command line.

This is not that simple. There are two problems:

1. The fact that some applications don't support that the file is zeroed
and removed by Mutt. Note that some Linux applications have the same
problem. I don't think this is a deficiency, in particular if the file
is large. In fact, Mutt has a similar behavior: if you remove a mailbox
after loading it into Mutt, Mutt will complain when trying to read
messages.

2. The security problem mentioned in my previous message. If fact, one
can explicitly tell "open" which application to use, but this is not
practical (e.g. if one upgrades OpenOffice, one also needs to upgrade
the mailcap file, because the version number is part of the application
name).

> If I ever did use OS X, I doubt I would read my mail there. Then
> again, while there are always exceptions, I tend to save attachments
> before viewing them anyway, so it's (for me) mostly a moot point.

I also do that (mainly when I need to keep the attachment). But this
is less practical than typing [Return] to view the attachment.

> [As a side note, I read my personal mail on a remote server, so
> mailcap is almost completely irrelevant in that case.  I transfer
> attachments to my local machine, in the exceptionally rare case when I
> receive something I actually want to look at, since in most cases
> that's much faster than waiting for remote X clients -- and then I
> need to transfer the file anyway to work with it.  My work mail I
> do read on my local workstation, and that's where the above applies.]

It would probably be better to have a wrapper script that transfers
the attachment on the local machine and launches a local X client (this
probably needs a daemon on the local side, or a modified terminal to
use a protocol so that the terminal can execute commands from escape
sequences).

I run Mutt in a screen session, which I can use either locally or
remotely via ssh. So, locally I have an X11 access (or the Mac OS X
desktop), and remotely, I don't have an X11 access (I usually do not
forward X11 for the reason you gave).

> > Also your mailcap is simplistic. In practice, you should test that
> > DISPLAY is set before starting an X11 client, so that a fallback can
> > be used.
> 
> I think I'm perfectly capable of figuring out whether I'm running in X
> or not...

I also know when I'm running X or not, but the mailcap system also
needs to know that so that...

> If I'm not in X I probably can't view PDF files anyway, at least not
> in any useful capacity.

Some PDF files are perfectly viewable in a text terminal (many of them
just contain text). For those PDF files, I'd like to be able to view
them in the terminal. One could say the same thing for HTML.

> Your assertion that I *need* to write code to support all this is
> false, and completely absurd, like most of your other points.  I don't
> need to, and have not ever done so.

And in the same way, most users don't need to write code to use an
editor.

> Given that vi is adhering strictly to (at least one revision of) the
> rather widely accepted and complied-to POSIX standards, that position
> is completely unsupportable.

No, I think that SCO and Solaris just had a buggy interpretation of
POSIX, which says for vi:

EXIT STATUS

The following exit values shall be returned:

 0
Successful completion.
>0
An error occurred.

IMHO, when saying "an error occurred", this implicitly means during
the completion (i.e. after the last interactive operation). There
can be an error during the editing, but if the completion is fine,
then this is a successful completion and the editor can return 0.

Of course, this must not be confused with the following:

  When any error is encountered and the standard input is not a
  terminal device file, vi shall not write the file or return to
  command or text input mode, and shall terminate with a non-zero
  exit status.

which more or less deals with the case where vi is run in a
non-interactive way.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Feature request for somewhen

[David Woodfall]

On (20:58 16/06/07), Adeodato Simó <[EMAIL PROTECTED]> put forth the 
proposition:
> * David Woodfall [Sat, 16 Jun 2007 00:07:50 +0100]:
> 
> > When entering an mbox from a folder, and then exiting back to the folder,
> > presently the cursor returns to the top of the folder. It would be nice if
> > the cursor remained opposite the mbox exited from, in the same way that
> > when browsing an mbox and exiting an email/thread does.
> 
> > It would save an awful lot of scrolling down when, say, checking new posts
> > in mailing lists.
> 
> > Just a thought anyway.
> 
> Hello. The feature you want is implemented in the sensible_browser_position
> patch by Haakon Riiser:
> 
>   http://does-not-exist.org/mail-archives/mutt-dev/msg02623.html
> OR
>   
> http://hg.debian.org/hg/pkg-mutt/debian-mutt?cmd=file;file=debian/patches/not-applied/patch-1.5.8.hr.sensible_browser_position.3;filenode=4f3e410fcc58a5721d0c7910a8ab2e2cd1996d22;style=raw

Thanks for that - I'll give it a shot.

> 
> I suggested it for 1.6, but received no feedback AFAICR.
> 
> Cheers,
> 
> -- 
> Adeodato Simó dato at net.com.org.es
> Debian Developer  adeodato at debian.org
>  
> This is my boyfriend, Chester Fleet. [...] It's kind of a weird day to meet 
> him
> because he lost a bet with me, and that means that for the entire day, he can
> only talk in clichés. It is so much fun.
> -- Tana Schrick

-- 
"Acting is an art which consists of keeping the audience from
coughing."

[Mutt] #2913: no locale for gpgme context set

[Mutt]

#2913: no locale for gpgme context set

 If mutt crypto backend is GPGME passphrase input is handled by external
 tools. AFAIK gpg-agent is invoked which calls pinentry. On this way a
 locale setting has to be handed over. As long as mutt is concerned, the
 locale setting of the console mutt was started at has to be handed over to
 GPGME. Documentation of GPGME says:

  File: gpgme.info,  Node: Locale,  Prev: Progress Meter Callback,  Up:
 Context
  Attributes

  7.3.9 Locale
  

  A locale setting can be associated with a context.  This locale is
  passed to the crypto engine, and used for applications like the PIN
  entry, which is displayed to the user when entering a passphrase is
  required.

The default locale is used to initialize the locale setting of all
contexts created afterwards.

  -- Function: gpgme_error_t gpgme_set_locale (gpgme_ctx_t CTX, int
 CATEGORY, const char *VALUE)
  The function `gpgme_set_locale' sets the locale of the context
  CTX, or the default locale if CTX is a null pointer.

  The locale settings that should be changed are specified by
  CATEGORY.  Supported categories are `LC_CTYPE', `LC_MESSAGES', and
  `LC_ALL', which is a wildcard you can use if you want to change
  all the categories at once.

  The value to be used for the locale setting is VALUE, which will
  be copied to GPGME's internal data structures.  VALUE can be a
  null pointer, which disables setting the locale, and will make PIN
  entry and other applications use their default setting, which is
  usually not what you want.

  Note that the settings are only used if the application runs on a
  text terminal, and that the settings should fit the configuration
  of the output terminal.  Normally, it is sufficient to initialize
  the default value at startup.

  The function returns an error if not enough memory is available.

 I assume it would be the easiest to pass the locale directly after each
 (of the 4) invocation of ''gpgme_new'' in file ''crypt-gpgme.c''.

-- 
Ticket URL: 

Re: [ANNOUNCE] mutt 1.5.16 released

[Kyle Wheeler]

On Sunday, June 17 at 10:06 PM, quoth Vincent Lefevre:

image/*; open %s; copiousoutput; nametemplate=%s.jpg
text/html; elinks -dump -force-html %s; needsterminal; copiousoutput;
application/pdf; open %s; copiousoutput; nametemplate=%s.pdf
application/msword; open %s; copiousoutput; nametemplate=%s.doc
application/excel; open %s; copiousoutput; nametemplate=%s.xls


Before giving rules, perhaps you should make sure that they really 
work everywhere. I can tell you that this doesn't work on my machine, 
at least for PDF. You have a race condition here: the "open" command 
can return before the application (here, Preview) loads the file.


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.


You can even check my facts in the mutt source. Mutt will only unlink 
the file after having done a mutt_do_pager (which doesn't return until 
the pager exits).


The fact that my machine is a fast bi-processor machine can have an 
impact on the probability of failure. But I suggest that you try 
that on such a machine (if you can) with Preview already loaded.


Can you stick your nose any further up in the air about your fancy 
computer?


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.


I also need a mailcap that works on various machines, where the 
current environment is an X11 one or not (hence the test of the 
DISPLAY environment variable).


Fair enough, but that's not the general case, and so has no bearing on 
the claim that you need to write code just to use mailcap on MacOS X.



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.


~Kyle
--
America will never be destroyed from the outside. If we falter and 
lose our freedoms, it will be because we destroyed ourselves.

-- Abraham Lincoln


pgpiC4sYCguHo.pgp
Description: PGP signature

Re: [ANNOUNCE] mutt 1.5.16 released

[Brendan Cully]

On Sunday, 17 June 2007 at 19:46, Kyle Wheeler wrote:
> On Sunday, June 17 at 10:06 PM, quoth Vincent Lefevre:
>>> image/*; open %s; copiousoutput; nametemplate=%s.jpg
>>> text/html; elinks -dump -force-html %s; needsterminal; copiousoutput;
>>> application/pdf; open %s; copiousoutput; nametemplate=%s.pdf
>>> application/msword; open %s; copiousoutput; nametemplate=%s.doc
>>> application/excel; open %s; copiousoutput; nametemplate=%s.xls
>>
>> Before giving rules, perhaps you should make sure that they really work 
>> everywhere. I can tell you that this doesn't work on my machine, at least 
>> for PDF. You have a race condition here: the "open" command can return 
>> before the application (here, Preview) loads the file.
>
> While you're lecturing me, maybe you can read what I wrote. There's 

Gentlemen, can we end this thread? I haven't been reading it for about
the last 30 messages, and I suspect you'd be better off if you stopped
too :)

Re: [ANNOUNCE] mutt 1.5.16 released

[Vincent Lefevre]

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 <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)