Re: [Nmh-workers] proposed patch for shell metacharacter failure in nmh-1.7

[Steven Winikoff]

>I'm wondering if this is the correct approach.
>
>It seems kind of fragile to me to try quoting these characters, assuming
>we are passing the entire line for mhshow entries to /bin/sh -c, since
>we don't have any idea what that command line looks like

I'm not up to speed on the code in nmh (other than having looked at just
enough of mhshowsbr.c to have proposed the parentheses patch in the first
place).

...but my experience working with /bin/sh in other matters over the years
suggests that the safest thing to do is always to quote shell metacharacters
you aren't deliberately intending to interpret.


>(although ...  I don't think I really understand why Steven is using
>%{name},

I have a script which, given the message part corresponding to an
attachment, copies that attachment to a known directory on the machine
whose console I'm sitting at (which may or may not be the same machine
where nmh is running).

It's certainly possible to use the basename constructed by mhshow, but
I find it more useful to save the attachment under its real name if/when
that name can be determined.  That's why I want the value of %{name} here.

For years I was using single quotes around the values of all of the mhshow
escapes in my .mh_profile, but I recently learned that's not supposed to
be necessary.

...but whether I used single quotes or not, some filenames were causing
problems for me.  That's where this whole discussion began, since the
problem presented itself as an error interpreting ( and ) in the filename.
David convinced me that double-quoting %{name} accomplishes the same goal
as my proposed patch, which is therefore unnecessary.

However, there's certainly still some unexpected behaviour going on; when
I run "%{name}" through an RFC-2047 decoder (using David's suggested usage
of fmttest, or with a standalone python script I tried earlier today, the
entire string passed into my script is single-quoted even though the quote
marks aren't part of the decoded filename.

Whether this (or anything else I may not have run into :-) is actually
a problem which needs to be solved is something I'll leave to you and
others who know the code better than I do.


>I really think to be safe we should simply replace any shell
>metacharacters for those things, because I can imagine some nasty
>security holes that we might encounter.

That's a stronger version of what I was trying to say above. :-)

     - Steven
-- 
___________________________________________________________________________
Steven Winikoff                |
Concordia University           | "This sentence contradicts itself;
Montreal, QC, Canada           |  well, no, actually it doesn't."
address@hidden   |
                               |                    - Douglas Hofstadter