ietf-822
[Top] [All Lists]

Re: trojan horses in RFC XXXX mail (tex/troff/postscript considered harmful)

1991-10-31 14:37:50

I've been following the mailing list for a few months now, and thought
I'd finally add my two cents worth now that they actually might contribute
something..

Note that in the case of PostScript (and Display PostScript), the
dangerous "file" operators have been crippled in the name of security.
For example, on the NeXT, you cannot create a file using the file
operator in PostScript, only open existing files for reading.

Now sure, this eliminates a large class of security problems, but also
renders certain types of things impossible.  You have to be careful
where you decide to enforce security policy so that you don't prevent
or prohibit otherwise resonable things from being done.  In my
opinion, what was done in Display PostScript on the NeXT was going a
little too far.

I'm strongly for providing the mechanism and perhaps pointing out
where policy might be "inflicted" by the application.  But it is an
application issue, and not one of the protocol itself.

While I'm at it, I'd support an Audio type with the header and so
forth, and specify that minimally support of 8kHz u-law audio be
present.  Having the header for the sound file present means that
consenting UI's can use the same transport to send, e.g., 16bit 44kHz
stereo sound.

Louis Mamakos