regarding your comments on proposed media type text/troff' to Informational RFC

[blilly at erols.com (Bruce Lilly)]

On Thu April 14 2005 22:49, Keith Moore wrote:
> [cc'ed to ietf-types list, which per RFC 2048 is where this document 
> should be reviewed.]

Pre-draft discussions and earlier drafts have been discussed on
ietf-types; as the current draft is in Last Call, I've restored
copies to the IESG list.

> Bruce,
> 
> I raise this concern both because this was something that was discussed 
> extensively in the ietf-822 working group that created MIME, and also 
> because we've seen far too many security holes result from giving the 
> sender a way to choose what program to run on the recipient's system 

The "process" parameter is explicitly *NOT* "giving the sender a way to
choose what program to run on the recipient's system".  It is a way for
the sender to suggest a recommended processing sequence to the human
recipient.  N.B. "suggest", "recommended", and "human".

> (usually by ignoring the content-type parameter and paying attention to 
> the application-specific filename suffix).

There is a detailed discussion of suffixes (a.k.a. "extensions") in the
draft.

> Even if we don't think  
> troff will be used much, it sets a bad precedent to allow a new 
> content-type to specify something that we have ample experience to 
> indicate it's harmful.
> 
> RFC 2046 (section 4.5.1) even includes the following language, which 
> also appeared in RFCs 1341 and 1521:
> 
> >    To reduce the danger of transmitting rogue programs, it is strongly
> >    recommended that implementations NOT implement a path-search
> >    mechanism whereby an arbitrary program named in the Content-Type
> >    parameter (e.g., an "interpreter=" parameter) is found and executed
> >    using the message body as input.

I fully agree that implementations should take suitable precautions. I
would (and have in the draft) go farther and state that implementations
(w.r.t. text/troff) should not automatically process content other than
possibly stripping directives for presentation.  And there are some
specific additional recommendations for safe presentation whether or
not directives are stripped (e.g. precautions against control
characters). 

> now this is in a section related to the application/octet-stream 
> content-type, but the principle is the same - if you let the sender 
> choose what programs should be used to process the input, the 
> content-type label is effectively ignored.

Again, that's not what is being done.

> And the only difference  
> between an "interpreter" parameter and a "process" parameter is that 
> you're not only letting the sender specify the interpreter, you're 
> letting him specify the entire command line!

Either way, we're agreed that *implementations* should not automatically
execute such programs.

> I don't think it matters much if you say "don't directly execute the 
> process parameter" because the very purpose of the process parameter is 
> to tell the sender exactly what to type,

ITYM "recipient".  And it's a suggestion, not an imperative.

> and to allow the sender to  
> specify arbitrary preprocessing programs and arbitrary parameters to 
> those programs.

The intent is to specify the preprocessors and parameters which will
produce the output that the author intended, not arbitrary progams/
parameters.  Certainly the mechanism could be abused, just as sending
a plain text message ("social engineering") can be abused.

> Maybe recipients should know better than type  
> arbitrary commands specified by the sender, but there's ample 
> experience to suggest that most recipients don't have that kind of 
> expertise.

The nature of the text media type is that subtypes of that type are
(supposed to be) presentable to a user w/o processing of any type (as
discussed in some detail in the draft).  As with some other "rich" text
subtypes, the proposed text/troff may also be processed for improved
presentation (e.g. to produce hard copy).  The "process" parameter
merely provides hints for the recipient to perform such processing
*IF* the recipient decides to do so.

> Nor am I persuaded by the "sender must specify the order of 
> preprocessing" argument, as groff has options to specify which of 
> several preprocessors to use, and it seems to work fine.

At the risk of being repetitive, no, groff's limited facility is
inadequate:

o groff is not installed everywhere

o there are different versions of groff; some have no support for the
  grap preprocessor

o no version of groff up to the present one has support for either chem
  or dformat preprocessors, or for preprocessors such as the one for
  handling ABNF

o groff uses fixed order of preprocessing, with eqn last.  That fails
  miserably for documents with equations in graphs (CSTR 114) or with
  equations in tables (CSTR 49) or both

o groff's fixed order does not accommodate tables in diagrams, which is
  certainly possible.

> The Version 7  
> UNIX versions of these tools (circa 1979) described in the "CSTR 49" 
> document you cite had several limitations (many related to having to 
> run in 64k of code space on a pdp 11/70), that don't apply to modern 
> troff implementations.

How is that relevant?  The CSTR documents have been updated.  Moreover,
the primary consideration is the order which is necessary to produce
proper formatted output; the order that works for tables in diagrams is
different from the order that works for diagrams in tables, in a
mutually exclusive relationship (i.e. there is no order that will cover
both cases).