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

[Ken Hornstein]

>> There are two things here.  First, the function we created called argsplit(),
>> which we use to generate an argv[] array.  We space-split that, unless we
>> find a shell metacharacter; if we see one, we pass it to /bin/sh -c.
>
>Has that turned out to be a good idea?  For example:

Weeeellll ... maybe?

I think the idea was that we wanted to enable things like this in your
.mh_profile:

moreproc: less "-PMsome stuff here"

So in other words, we wanted to enable shell metacharacters without doing
any of the parsing.

At the time, we didn't have the ability to bring in MIME parameters (although
I guess we could put the content-type, but mhshow entries were always run
with /bin/sh I think).

>> My
>> proposal is to simply edit out shell metacharacters (add # and ! like
>> David suggested) in those strings.  That seems simple and reasonable to me.
>> Well, maybe replace them with an _ or something.
>
>Paul V wrote in response:
>
>% i think editing of that kind will violate the principle of least 
>astonishment.
>
>+1  I'll go further, I think it's a bad idea.

I'm trying to understand the problem.  For MOST MIME parameters, they
shouldn't have shell metacharacters.  For filenames ... well, plenty
of programs sanitize those filenames now anyway.  If you want to store
something with the real filename there is always mhstore and mhlist.
I'm only proposing doing this for the case where nmh programs directly
run programs that can take MIME parameter arguments (which, AFIAK, is
only mhshow).

>My point in mentioning # and ! was that METACHARS was incomplete.  Also,
>it's dependent on the user's particular shell.

I think we decided we would unilaterally always use /bin/sh, right?

>Would execve() solve all of these problems?

With some reduced functionality.  If that's acceptable, then I guess that's
okay.  No answers are wonderful.

--Ken